GNU bug report logs - #51128
timeout --kill-after=0 seems to not send a kill 0s after the initial signal

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 51128 in the body.
You can then email your comments to 51128 AT debbugs.gnu.org in the normal way.

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

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 --kill-after=0 seems to not send a kill 0s after the
 initial signal
Date: Mon, 11 Oct 2021 03:28:12 +0200

Hey.

The timeout(1) manpage says:
       -k, --kill-after=DURATION
              also send a KILL signal if COMMAND is still running
              this long after the initial signal was sent

My naive assumption would have been that --kill-after=0 means that a
signal is sent immediately after the original one.

However, that doesn't seem to be the case.


If intended, this should perhaps at least be mentioned in the manpage
:-)


Cheers,
Chris.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Mon, 11 Oct 2021 16:49:38 +0100

tag 51128 notabug
close 51128
stop

On 11/10/2021 02:28, Christoph Anton Mitterer wrote:
> Hey.
> 
> The timeout(1) manpage says:
>         -k, --kill-after=DURATION
>                also send a KILL signal if COMMAND is still running
>                this long after the initial signal was sent
> 
> My naive assumption would have been that --kill-after=0 means that a
> signal is sent immediately after the original one.

Well that wouldn't be that useful functionality,
as why not just send a single kill signal in that case.

> However, that doesn't seem to be the case.
> 
> 
> If intended, this should perhaps at least be mentioned in the manpage
> :-)

It is intended that a 0 duration disables that timeout.
It is mentioned in the full documentation at:
https://www.gnu.org/software/coreutils/timeout
The man pages don't try to document every nuance.

cheers,
Pádraig.

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

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Mon, 11 Oct 2021 17:59:42 +0200

On Mon, 2021-10-11 at 16:49 +0100, Pádraig Brady wrote:
> Well that wouldn't be that useful functionality,
> as why not just send a single kill signal in that case.

Well with the same argumentation one could say that timeout 0 command
doesn’t execute the command at all, since why should one call it with a
timeout, when there's anyway none?

Also it may make "sense" if the value is configurable e.g. via some
user input made before,...


And in my opinion, since this behaviour is really quite unexpected
(disabling an option, though explicitly setting it), it should at least
also be mentioned in the manpage, too.


Anyway,.. cheers,
Chris.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Mon, 11 Oct 2021 21:29:58 +0100

On 11/10/2021 16:59, Christoph Anton Mitterer wrote:
> On Mon, 2021-10-11 at 16:49 +0100, Pádraig Brady wrote:
>> Well that wouldn't be that useful functionality,
>> as why not just send a single kill signal in that case.
> 
> Well with the same argumentation one could say that timeout 0 command
> doesn’t execute the command at all, since why should one call it with a
> timeout, when there's anyway none?

It's more consistent for a duration of 0 to disable the associated timeout.

> Also it may make "sense" if the value is configurable e.g. via some
> user input made before,...

Exactly. A propagated user setting of 0 should be interpreted as
disabling the timeouts rather than the command itself,
as timing out immediately is not useful functionality.

> And in my opinion, since this behaviour is really quite unexpected
> (disabling an option, though explicitly setting it), it should at least
> also be mentioned in the manpage, too.

The man page mentions this for DURATION (and thus for both timeouts mentioned above):
"A duration of 0 disables the associated timeout"

thanks,
Pádraig

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

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Tue, 12 Oct 2021 03:21:34 +0200

Hey.

One more thing on this, since I've just read through:
https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation

That does IMO *not* document the behaviour:

--kill-after=duration says:
>This option has no effect if timeout’s duration is 0 which disables
>the associated timeout. 

But that's about the timeout from the command itself (i.e. the 1st non-
option argument), isn't it?

So it means that if I have:

timeout --kill-after=10 0 ./command

There won't be a KILL after 10s, since the duration itself is 0.


There's no word about that --kill-after=0 disabling the KILL in the
duration != 0 case as in:
timeout --kill-after=0 10 ./command


Cheers,
Chris.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Christoph Anton Mitterer <calestyo <at> scientia.net>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Tue, 12 Oct 2021 14:53:17 +0100

On 12/10/2021 02:21, Christoph Anton Mitterer wrote:
> Hey.
> 
> One more thing on this, since I've just read through:
> https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
> 
> That does IMO *not* document the behaviour:
> 
> --kill-after=duration says:
>> This option has no effect if timeout’s duration is 0 which disables
>> the associated timeout.
> 
> But that's about the timeout from the command itself (i.e. the 1st non-
> option argument), isn't it?
> 
> So it means that if I have:
> 
> timeout --kill-after=10 0 ./command
> 
> There won't be a KILL after 10s, since the duration itself is 0.

Right. That is the behavior.

> There's no word about that --kill-after=0 disabling the KILL in the
> duration != 0 case as in:
> timeout --kill-after=0 10 ./command

Well DURATIONs of 0 were mentioned a little below that.
But it it worth clarifying in the option description itself.
So I'll make the following change:

-This option has no effect if @command{timeout}'s duration is 0 which
-disables the associated timeout.
+This option has no effect if either the main @var{duration}
+of the @command{timeout} command, or the @var{duration} specified
+to this option, is 0.

cheers,
Pádraig

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

From: Christoph Anton Mitterer <calestyo <at> scientia.net>
To: Pádraig Brady <P <at> draigBrady.com>, 51128 <at> debbugs.gnu.org
Subject: Re: bug#51128: timeout --kill-after=0 seems to not send a kill 0s
 after the initial signal
Date: Tue, 12 Oct 2021 16:03:29 +0200

On Tue, 2021-10-12 at 14:53 +0100, Pádraig Brady wrote:
> Well DURATIONs of 0 were mentioned a little below that.

Hmm ok,... I see, since both use the symbol <duration>... and you use
the word "associated"... one could have also understood it from the
beginning like that.


> -This option has no effect if @command{timeout}'s duration is 0 which
> -disables the associated timeout.
> +This option has no effect if either the main @var{duration}
> +of the @command{timeout} command, or the @var{duration} specified
> +to this option, is 0.

Much better though IMO :-)


Thanks,
Chris.

Previous Next

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