GNU bug report logs -
#70219
Bug/Issue with timeout and signals
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 70219 in the body.
You can then email your comments to 70219 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#70219; Package
coreutils.
(Fri, 05 Apr 2024 18:01:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Branden R. Williams" <brw <at> brandenwilliams.com>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Fri, 05 Apr 2024 18:01:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I was integrating the timeout command into a shell script and realized the manpage & the --help docs do not accurately describe how the tool works. In addition, there appears to be a bug related to arguments passed. I am running version 9.1.
According to the help screen, this command should work:
timeout -k 10s ping example.com <http://example.com/>
It fails, however, because the next argument after invoking -k is the kill signal you want to send. The command (to send a SIGKILL) must be:
timeout -k 9 10s ping example.com <http://example.com/>
I believe the kill after functionality and docs should be modified to send a default signal of SIGTERM without an additional argument so the first iteration above would work. Then you could explain that if you wanted to send a DIFFERENT signal, use the -s flag that is there to pass one. But according to the docs, the first command SHOULD work. Even using the --kill-after= syntax passes in the kill signal into that argument, not the actual time.
Thank you for your consideration and for maintaining such a critical set of tools!
Regards,
B
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Fri, 05 Apr 2024 22:00:05 GMT)
Full text and
rfc822 format available.
Message #8 received at 70219 <at> debbugs.gnu.org (full text, mbox):
On 05/04/2024 at 16:19, Branden R. Williams via GNU coreutils Bug
Reports wrote:
> I was integrating the timeout command into a shell script and realized the manpage & the --help docs do not accurately describe how the tool works. In addition, there appears to be a bug related to arguments passed. I am running version 9.1.
>
> According to the help screen, this command should work:
>
> timeout -k 10s ping example.com <http://example.com/>
>
> It fails, however, because the next argument after invoking -k is the kill signal you want to send. The command (to send a SIGKILL) must be:
>
As I understand it, the argument after -k (or --kill-after=) is the time
to wait and send the kill signal if the timeout fails.
So this line:
> timeout -k 9 10s ping example.com <http://example.com/>
>
sends a kill signal 9 seconds after the timeout, if the timeout hasn't
worked.
The -s option is to change the signal sent (as below).
> I believe the kill after functionality and docs should be modified to send a default signal of SIGTERM without an additional argument so the first iteration above would work. Then you could explain that if you wanted to send a DIFFERENT signal, use the -s flag that is there to pass one. But according to the docs, the first command SHOULD work. Even using the --kill-after= syntax passes in the kill signal into that argument, not the actual time.
>
> Thank you for your consideration and for maintaining such a critical set of tools!
>
> Regards,
>
> B
>
>
--
Chris Elvidge
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 06:39:07 GMT)
Full text and
rfc822 format available.
Message #11 received at 70219 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
That’s not an accurate representation of what the command actually does. The argument after -k MUST be the kill signal code, without the code the command fails. The manpage and help document agree with what you are saying but the execution of the program fails.
That functionality is not represented in the manpage or --help. If you used -k 10 10s it would send a SIGTERM vs SIGKILL. The point is that the argument immediately after the -k or --kill-after= is the kill signal code, not the duration. The manpage and help file suggest that it should be the duration.
That’s why I am suggesting using a default SIGTERM if the -k or --kill-after= is passed so that the duration is the actual argument that follows. If you wanted to alter the signal, that’s where the -s flag comes in.
> On Apr 5, 2024, at 4:59 PM, Chris Elvidge <celvidge001 <at> gmail.com> wrote:
>
>
>
> On 05/04/2024 at 16:19, Branden R. Williams via GNU coreutils Bug Reports wrote:
>> I was integrating the timeout command into a shell script and realized the manpage & the --help docs do not accurately describe how the tool works. In addition, there appears to be a bug related to arguments passed. I am running version 9.1.
>> According to the help screen, this command should work:
>> timeout -k 10s ping https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=1o61i4CUhS9OzzVMraHh20b966TBpqSO4_0GGRNaLWA&m=aJDfsufl90pc4lE-vjk1Oo94O1RIrEP39t_G7X5-pvl_5ZXtR-2jcnl0a5OxJgGu&s=VjTsmLfaTKmXMJL0S6OXC7PHTK-rxRwmG7skx4FheqY&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=1o61i4CUhS9OzzVMraHh20b966TBpqSO4_0GGRNaLWA&m=aJDfsufl90pc4lE-vjk1Oo94O1RIrEP39t_G7X5-pvl_5ZXtR-2jcnl0a5OxJgGu&s=i2LYw6g0va2Fbz-arA9sTJOn7_G1uY3hN2Pf5pLautc&e=>
>> It fails, however, because the next argument after invoking -k is the kill signal you want to send. The command (to send a SIGKILL) must be:
>
> As I understand it, the argument after -k (or --kill-after=) is the time to wait and send the kill signal if the timeout fails.
> So this line:
>
>> timeout -k 9 10s ping https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=1o61i4CUhS9OzzVMraHh20b966TBpqSO4_0GGRNaLWA&m=aJDfsufl90pc4lE-vjk1Oo94O1RIrEP39t_G7X5-pvl_5ZXtR-2jcnl0a5OxJgGu&s=VjTsmLfaTKmXMJL0S6OXC7PHTK-rxRwmG7skx4FheqY&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=1o61i4CUhS9OzzVMraHh20b966TBpqSO4_0GGRNaLWA&m=aJDfsufl90pc4lE-vjk1Oo94O1RIrEP39t_G7X5-pvl_5ZXtR-2jcnl0a5OxJgGu&s=i2LYw6g0va2Fbz-arA9sTJOn7_G1uY3hN2Pf5pLautc&e=>
>
> sends a kill signal 9 seconds after the timeout, if the timeout hasn't worked.
>
> The -s option is to change the signal sent (as below).
>
>> I believe the kill after functionality and docs should be modified to send a default signal of SIGTERM without an additional argument so the first iteration above would work. Then you could explain that if you wanted to send a DIFFERENT signal, use the -s flag that is there to pass one. But according to the docs, the first command SHOULD work. Even using the --kill-after= syntax passes in the kill signal into that argument, not the actual time.
>> Thank you for your consideration and for maintaining such a critical set of tools!
>> Regards,
>> B
>
>
> --
>
> Chris Elvidge
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 09:08:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
> That’s not an accurate representation of what the command actually does. The argument after -k MUST be the kill signal code, without the code the command fails. The manpage and help document agree with what you are saying but the execution of the program fails.
$ timeout -k USR1 1s sleep 10
timeout: invalid time interval ‘USR1’
Try 'timeout --help' for more information.
$ timeout -s KILL 1s sleep 10
Killed
--
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 09:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 14:45:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 70219 <at> debbugs.gnu.org (full text, mbox):
Branden,
Then how come timeout -k 10s 20s ping 8.8.8.8 works?
10s is DEFINITELY NOT an integer. 20s in the timeout value.
I still think your reasoning is suspect.
On 06/04/2024 at 13:43, Branden R. Williams wrote:
> I understand this, but the manpage and the help file do not explain the
> functionally this way. The manpage suggests that the following should work:
>
> $ timeout -k 10s sleep 10
>
> It does not because the first argument after -k MUST be the an integer
> value of the signal you want to send, not the duration that the manpage
> and --help tell you to pass.
>
> Regards,
>
> B
>
>
>
>> On Apr 6, 2024, at 4:06 AM, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>>
>> On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
>>
>>> That’s not an accurate representation of what the command actually
>>> does. The argument after -k MUST be the kill signal code, without the
>>> code the command fails. The manpage and help document agree with what
>>> you are saying but the execution of the program fails.
>>
>> $ timeout -k USR1 1s sleep 10
>> timeout: invalid time interval ‘USR1’
>> Try 'timeout --help' for more information.
>> $ timeout -s KILL 1s sleep 10
>> Killed
>>
>> --
>> Andreas Schwab, schwab <at> linux-m68k.org
>> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
>> "And now for something completely different."
>
--
Chris Elvidge
5 Ebor Park, Appleton Roebuck, York, Nor
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 17:10:04 GMT)
Full text and
rfc822 format available.
Message #23 received at 70219 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I understand this, but the manpage and the help file do not explain the functionally this way. The manpage suggests that the following should work:
$ timeout -k 10s sleep 10
It does not because the first argument after -k MUST be the an integer value of the signal you want to send, not the duration that the manpage and --help tell you to pass.
Regards,
B
> On Apr 6, 2024, at 4:06 AM, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>
> On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
>
>> That’s not an accurate representation of what the command actually does. The argument after -k MUST be the kill signal code, without the code the command fails. The manpage and help document agree with what you are saying but the execution of the program fails.
>
> $ timeout -k USR1 1s sleep 10
> timeout: invalid time interval ‘USR1’
> Try 'timeout --help' for more information.
> $ timeout -s KILL 1s sleep 10
> Killed
>
> --
> Andreas Schwab, schwab <at> linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
> "And now for something completely different."
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 17:10:05 GMT)
Full text and
rfc822 format available.
Message #26 received at 70219 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Working from the code published here: https://github.com/coreutils/coreutils/blob/master/src/timeout.c
If you look at the code, you can see the kill_after variable set on line 486 if the switch is there. In the cleanup() function on line 202, it looks for that variable to be st on line 212, then sets the kill signal to be SIGKILL and sets the timeout. But on line 578, the timeout is overridden anyway by the timeout variable obtained from the argv on line 520. So as I stated previously, if the goal of the -k is to send SIGKILL, it should not be a kill_after or require any seconds to be sent. What is happening on line 485 is it is capturing what SHOULD be the duration passed to “timeout” to kill_after, and then the timeout that is attempted to be grabbed in line 520 is literally the command you are wanting to run the timeout against.
It does not appear to matter what you pass into -k as it is never used in practice. -k does not do this:
-k, --kill-after=DURATION
also send a KILL signal if COMMAND is still running
this long after the initial signal was sent
It’s a logic bug. The -k flag should not take a duration, but just set the kill signal to SIGKILL. See this example where the 2s is captured on line 486 leaving nothing for line 520.
$ timeout -k 2s ping 8.8.8.8
timeout: invalid time interval ‘ping’
Try 'timeout --help' for more information.
See these examples of passing garbage into the -k flag:
$ timeout -k 2s 2s ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=2.02 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=1.92 ms
$ timeout -k 32s 2s ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=2.37 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=1.94 ms
$ timeout -k 92s 2s ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=1.94 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=8.38 ms
$ timeout -k 9265535s 2s ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=8.77 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=11.8 ms
$ timeout 2s ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=114 time=1.94 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=114 time=2.00 ms
Regards,
B
> On Apr 6, 2024, at 9:44 AM, Chris Elvidge <celvidge001 <at> gmail.com> wrote:
>
> Branden,
>
> Then how come timeout -k 10s 20s ping 8.8.8.8 works?
> 10s is DEFINITELY NOT an integer. 20s in the timeout value.
>
> I still think your reasoning is suspect.
>
>
> On 06/04/2024 at 13:43, Branden R. Williams wrote:
>> I understand this, but the manpage and the help file do not explain the functionally this way. The manpage suggests that the following should work:
>> $ timeout -k 10s sleep 10
>> It does not because the first argument after -k MUST be the an integer value of the signal you want to send, not the duration that the manpage and --help tell you to pass.
>> Regards,
>> B
>>> On Apr 6, 2024, at 4:06 AM, Andreas Schwab <schwab <at> linux-m68k.org> wrote:
>>>
>>> On Apr 05 2024, "Branden R. Williams" via GNU coreutils Bug Reports wrote:
>>>
>>>> That’s not an accurate representation of what the command actually does. The argument after -k MUST be the kill signal code, without the code the command fails. The manpage and help document agree with what you are saying but the execution of the program fails.
>>>
>>> $ timeout -k USR1 1s sleep 10
>>> timeout: invalid time interval ‘USR1’
>>> Try 'timeout --help' for more information.
>>> $ timeout -s KILL 1s sleep 10
>>> Killed
>>>
>>> --
>>> Andreas Schwab, schwab <at> linux-m68k.org
>>> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
>>> "And now for something completely different."
>
>
> --
>
> Chris Elvidge
>
> 5 Ebor Park, Appleton Roebuck, York, Nor
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#70219; Package
coreutils.
(Sat, 06 Apr 2024 18:31:03 GMT)
Full text and
rfc822 format available.
Message #29 received at 70219 <at> debbugs.gnu.org (full text, mbox):
tag 70219 notabug
close 70219
stop
On 06/04/2024 16:50, Branden R. Williams via GNU coreutils Bug Reports wrote:
> -k, --kill-after=DURATION
> also send a KILL signal if COMMAND is still running
> this long after the initial signal was sent
If you read the above carefully, please note the words _also_ and _initial_.
I.e. -k will cause _another_ signal to be sent, iff the first doesn't terminate the command.
Hopefully this example with all pertinent options explains things.
I.e. the first signal sent after 1s is ignored,
and the second kill signal sent after another 2s forcefully kills the command.
$ date +%s; timeout -k 2s -s0 1s sleep inf; date +%s
1712427916
Killed
1712427919
cheers,
Pádraig
Added tag(s) notabug.
Request was from
Pádraig Brady <P <at> draigBrady.com>
to
control <at> debbugs.gnu.org.
(Sat, 06 Apr 2024 18:31:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
70219 <at> debbugs.gnu.org and "Branden R. Williams" <brw <at> brandenwilliams.com>
Request was from
Pádraig Brady <P <at> draigBrady.com>
to
control <at> debbugs.gnu.org.
(Sat, 06 Apr 2024 18:31:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 05 May 2024 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 11 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.