GNU bug report logs -
#51135
timeout: --foreground causes exit status 124, even if KILL was used
Previous Next
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.
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):
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):
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):
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):
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):
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):
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):
[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):
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.