#1076047 coreutils: timeout: doesn't properly intercept all deadly signals

Package:
coreutils
Source:
coreutils
Description:
GNU core utilities
Submitter:
наб
Date:
2025-12-22 12:25:02 UTC
Severity:
normal
#1076047#5
Date:
2024-07-09 21:21:36 UTC
From:
To:
Dear Maintainer,

POSIX.1-2024, XCU, timeout, ASYNCHRONOUS EVENTS:
117587  If the signal specified with the −s option, or any signal whose default action is to terminate
117588  the process, is delivered to the timeout utility, then unless the signal is SIGKILL or
117589  SIGSTOP, the timeout utility shall immediately send the same signal to the process or
117590  processes to which it would send a signal when the time limit is reached. If the delivered
117591  signal is SIGALRM, timeout may behave as if the time limit had been reached instead of
117592  sending SIGALRM.

And yet:
  $ /bin/timeout -v 1 env -I SYS sleep 20 &
  [2] 2588815
  $ kill -SYS $!
  $
  [2]-  Bad system call         /bin/timeout -v 1 env -I SYS sleep 20

A correct session looks like:
  $ timeout 1 env -I SYS sleep 20 &
  [2] 2588094
  $ kill -SYS $!
  timeout: env (group): sending SIGSYS
  $ timeout: env (group): sending SIGTERM
  [2]-  Exit 124                out/cmd/timeout 1 env -I SYS sleep 20
  $

Best,
#1076047#10
Date:
2024-07-09 22:31:15 UTC
From:
To:
Right, so POSIX states that timeout(1) should ensure
all termination signals terminate the monitored command.
Currently we only do this for a few terminal centric ones
like SIGINT, SIGQUIT, SIGHUP, ...

cheers,
Pádraig
#1076047#15
Date:
2025-12-22 12:23:32 UTC
From:
To:
Implemented in
https://github.com/coreutils/coreutils/commit/d0a51c614
cheers,
Padraig