GNU bug report logs - #51135
timeout: --foreground causes exit status 124, even if KILL was used

Previous Next

Package: coreutils;

Reported by: Christoph Anton Mitterer <calestyo <at> scientia.net>

Date: Mon, 11 Oct 2021 18:02:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 51135 in the body.
You can then email your comments to 51135 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Mon, 11 Oct 2021 18:02:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Christoph Anton Mitterer <calestyo <at> scientia.net>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Mon, 11 Oct 2021 18:02:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: bug-coreutils <at> gnu.org
Subject: timeout: --foreground causes exit status 124, even if KILL was used
Date: Mon, 11 Oct 2021 20:01:42 +0200
Hey.


This time I've also checked the 9.0 documentation (hopefully I wasn't
just too blind).


I noticed that whenever --foreround is used, timeout exits with a 124
status (instead of the documented 128+9) regardless of whether the KILL
is sent because of --signal=KILL or --kill-after=n .


Thanks,
Chris.

btw: I'm sill on Debian sid's 8.32 version of coreutils.




Reply sent to Pádraig Brady <P <at> draigBrady.com>:
You have taken responsibility. (Mon, 11 Oct 2021 21:05:01 GMT) Full text and rfc822 format available.

Notification sent to Christoph Anton Mitterer <calestyo <at> scientia.net>:
bug acknowledged by developer. (Mon, 11 Oct 2021 21:05:01 GMT) Full text and rfc822 format available.

Message #10 received at 51135-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>,
 51135-done <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even if
 KILL was used
Date: Mon, 11 Oct 2021 22:04:21 +0100
On 11/10/2021 19:01, Christoph Anton Mitterer wrote:
> Hey.
> 
> 
> This time I've also checked the 9.0 documentation (hopefully I wasn't
> just too blind).
> 
> 
> I noticed that whenever --foreground is used, timeout exits with a 124
> status (instead of the documented 128+9) regardless of whether the KILL
> is sent because of --signal=KILL or --kill-after=n .

Yes --foreground gives timeout(1) more control over the exit status in this case.
I'll add some clarification to the texinfo manual along these lines:


-In case of the @samp{KILL(9)} signal, @command{timeout} returns with
+In the case of the @samp{KILL(9)} signal, @command{timeout} returns with
 exit status 137, regardless of whether that signal is sent to @var{command}
 or to @command{timeout} itself, i.e., these cases cannot be distinguished.
 In the latter case, the @var{command} process may still be alive after
 @command{timeout} has forcefully been terminated.
+However if the @option{--foreground} option is specified then
+@command{timeout} will not send any signals to its own process,
+and so it will exit with one of the other exit status values detailed above.

thanks,
Pádraig




Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Mon, 11 Oct 2021 21:12:02 GMT) Full text and rfc822 format available.

Message #13 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even
 if KILL was used
Date: Mon, 11 Oct 2021 23:11:35 +0200
On Mon, 2021-10-11 at 22:04 +0100, Pádraig Brady wrote:
> +However if the @option{--foreground} option is specified then
> +@command{timeout} will not send any signals to its own process,
> +and so it will exit with one of the other exit status values
> detailed above.

So 137 is only used when the signal was sent to timeout itself?

I'd have actually found it quite nice if 137 was used *even* with
--foreground.

That way one could differentiate between whether COMMAND had the chance
to do cleanups, or whether the calling process should take care on
that.


For example, I use timeout with a program that reads a phassphrase and
prints it to stdout.
It disables the terminal's ECHO, so when it has to be killed, the
calling process would need to re-enable that mnually.


Cheers,
Chris.




Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Mon, 11 Oct 2021 21:21:02 GMT) Full text and rfc822 format available.

Message #16 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even if
 KILL was used
Date: Mon, 11 Oct 2021 22:20:34 +0100
On 11/10/2021 22:11, Christoph Anton Mitterer wrote:
> On Mon, 2021-10-11 at 22:04 +0100, Pádraig Brady wrote:
>> +However if the @option{--foreground} option is specified then
>> +@command{timeout} will not send any signals to its own process,
>> +and so it will exit with one of the other exit status values
>> detailed above.
> 
> So 137 is only used when the signal was sent to timeout itself?
> 
> I'd have actually found it quite nice if 137 was used *even* with
> --foreground.
> 
> That way one could differentiate between whether COMMAND had the chance
> to do cleanups, or whether the calling process should take care on
> that.
> 
> 
> For example, I use timeout with a program that reads a phassphrase and
> prints it to stdout.
> It disables the terminal's ECHO, so when it has to be killed, the
> calling process would need to re-enable that mnually.

For that use case it's probably best to use --preserve-status,
in which case the 137 from the child getting the SIGKILL
will be propagated through.




Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Mon, 11 Oct 2021 21:25:01 GMT) Full text and rfc822 format available.

Message #19 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even
 if KILL was used
Date: Mon, 11 Oct 2021 23:23:57 +0200
On Mon, 2021-10-11 at 22:20 +0100, Pádraig Brady wrote:
> For that use case it's probably best to use --preserve-status,
> in which case the 137 from the child getting the SIGKILL
> will be propagated through.

But wouldn't that make me loose the 124, if COMMAND could actually be
SIGTERMed?




Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Tue, 12 Oct 2021 01:56:02 GMT) Full text and rfc822 format available.

Message #22 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even
 if KILL was used
Date: Tue, 12 Oct 2021 03:55:03 +0200
Thinking again about this:

Don't you think one looses quite something if, with --foreground, one
cannot differ (via the exit status) between a timeout that allowed the
program to clean up and one (when KILLing) that didn't?


Even if the KILL happens via killing timeout itself, couldn't it just
return 128+9 in the case --foreground was enabled and the original
signal had already been sent?
Or is that technically not possible then?




Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Tue, 12 Oct 2021 13:51:02 GMT) Full text and rfc822 format available.

Message #25 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even if
 KILL was used
Date: Tue, 12 Oct 2021 14:50:38 +0100
[Message part 1 (text/plain, inline)]
On 12/10/2021 02:55, Christoph Anton Mitterer wrote:
> Thinking again about this:
> 
> Don't you think one looses quite something if, with --foreground, one
> cannot differ (via the exit status) between a timeout that allowed the
> program to clean up and one (when KILLing) that didn't?
> 
> 
> Even if the KILL happens via killing timeout itself, couldn't it just
> return 128+9 in the case --foreground was enabled and the original
> signal had already been sent?
> Or is that technically not possible then?

That is a fair point.
If one is using --kill-after you have to
check for both 124 and 137 anyway to see if it timed out.
It is useful to know whether the command was forcably killed.
Using --foreground to avoid the 137 exit status upon --kill-after
is not until now documented, so we should probably adjust
the exit status to be always 137 if a SIGKILL is sent.

With the attached we now behave like:

  $ timeout -v -s0 --foreground -k2 1 sleep 3; echo $?
  timeout: sending signal EXIT to command ‘sleep’
  timeout: sending signal KILL to command ‘sleep’
  137

  $ timeout -v -s0 -k2 1 sleep 3; echo $?
  timeout: sending signal EXIT to command ‘sleep’
  timeout: sending signal KILL to command ‘sleep’
  Killed
  137

cheers,
Pádraig
[timeout--foreground-k-status.patch (text/x-patch, attachment)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#51135; Package coreutils. (Tue, 12 Oct 2021 14:00:01 GMT) Full text and rfc822 format available.

Message #28 received at 51135 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51135 <at> debbugs.gnu.org
Subject: Re: bug#51135: timeout: --foreground causes exit status 124, even
 if KILL was used
Date: Tue, 12 Oct 2021 15:59:25 +0200
On Tue, 2021-10-12 at 14:50 +0100, Pádraig Brady wrote:
> That is a fair point.

Thanks for reconsidering :-)


> If one is using --kill-after you have to
> check for both 124 and 137 anyway to see if it timed out.
> It is useful to know whether the command was forcably killed.
> Using --foreground to avoid the 137 exit status upon --kill-after
> is not until now documented, so we should probably adjust
> the exit status to be always 137 if a SIGKILL is sent.
> 
> With the attached we now behave like:
> 
>    $ timeout -v -s0 --foreground -k2 1 sleep 3; echo $?
>    timeout: sending signal EXIT to command ‘sleep’
>    timeout: sending signal KILL to command ‘sleep’
>    137
> 
>    $ timeout -v -s0 -k2 1 sleep 3; echo $?
>    timeout: sending signal EXIT to command ‘sleep’
>    timeout: sending signal KILL to command ‘sleep’
>    Killed
>    137

Great :-)


Cheers,
Chris.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 10 Nov 2021 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 139 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.