GNU bug report logs - #41634
'timeout' returning 124 and 133

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 41634 in the body.
You can then email your comments to 41634 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: Jonny Grant <jg <at> jguk.org>
To: bug-coreutils <at> gnu.org
Subject: 'timeout' returning 124 and 133
Date: Sun, 31 May 2020 22:22:47 +0100

[Message part 1 (text/plain, inline)]

Hello

I'm using timeout with another program that doesn't have a timeout mechanism. Saw surprisingly timeout often returns 124

I was a bit surprised the return code as a signal was not 143 (128+ 15) for SIGTERM. I must be missing something.

This article says 124 for SIGTERM, and as expected 137 for SIGKILL (128+9)
https://www.howtogeek.com/423286/how-to-use-the-timeout-command-on-linux/

The man page says "Start COMMAND, and kill it if still running after DURATION.", it sounds like it's doing 'kill -s
SIGTERM' after DURATION. Then if -k argument it is doing 'kill -s SIGKILL'


Could the 124 and 137 be documented on the man page?

Regards, Jonny

[Message part 2 (text/html, inline)]

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Jonny Grant <jg <at> jguk.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Mon, 01 Jun 2020 08:53:36 +0200

On Mai 31 2020, Jonny Grant wrote:

> Could the 124 and 137 be documented on the man page?

What's wrong with the last paragraph in the DESCRIPTION section?

Andreas.

-- 
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 #11 received at 41634 <at> debbugs.gnu.org (full text, mbox):

From: Jonny Grant <jg <at> jguk.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Mon, 1 Jun 2020 09:01:38 +0100

On 01/06/2020 07:53, Andreas Schwab wrote:
> On Mai 31 2020, Jonny Grant wrote:
> 
>> Could the 124 and 137 be documented on the man page?
> 
> What's wrong with the last paragraph in the DESCRIPTION section?
> 
> Andreas.
> 

My mistake missing that. But could the 137 be listed explicitly?
ie.
"It may be  necessary  to  use the KILL (9) signal, since this signal cannot be caught, in which case the exit status is 
137 (128+9) rather than 124."

This other man page of timeout has a clearer list of the exit codes
https://ss64.com/bash/timeout.html

Jonny

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sat, 6 Jun 2020 01:37:46 +0200

[Message part 1 (text/plain, inline)]

On 2020-06-01 10:01, Jonny Grant wrote:
> My mistake missing that. But could the 137 be listed explicitly?
> ie.
> "It may be  necessary  to  use the KILL (9) signal, since this signal cannot be caught, in which case the exit status is 
> 137 (128+9) rather than 124."

thanks for the suggestion.

I think this could still be improved:
there is still the open question what happens when the KILL signal
is sent either to timeout(1) or to COMMAND.
The attached patch tries to clarify.

Have a nice day,
Berny

[0001-doc-timeout-further-clarify-exit-status-after-KILL-s.patch (text/x-patch, attachment)]

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sat, 6 Jun 2020 22:49:26 +0100

On 06/06/2020 00:37, Bernhard Voelker wrote:
> On 2020-06-01 10:01, Jonny Grant wrote:
>> My mistake missing that. But could the 137 be listed explicitly?
>> ie.
>> "It may be  necessary  to  use the KILL (9) signal, since this signal cannot be caught, in which case the exit status is
>> 137 (128+9) rather than 124."
> 
> thanks for the suggestion.
> 
> I think this could still be improved:
> there is still the open question what happens when the KILL signal
> is sent either to timeout(1) or to COMMAND.
> The attached patch tries to clarify.
> 
> Have a nice day,
> Berny
> 

Hello Berny

Great patch.

How about writing signal 9 by the name, ie $ kill -s KILL
likewise $ kill -s TERM

Cheers, Jonny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 13:13:21 +0100

[Message part 1 (text/plain, inline)]

On 06/06/2020 00:37, Bernhard Voelker wrote:
> On 2020-06-01 10:01, Jonny Grant wrote:
>> My mistake missing that. But could the 137 be listed explicitly?
>> ie.
>> "It may be  necessary  to  use the KILL (9) signal, since this signal cannot be caught, in which case the exit status is
>> 137 (128+9) rather than 124."
> 
> thanks for the suggestion.
> 
> I think this could still be improved:
> there is still the open question what happens when the KILL signal
> is sent either to timeout(1) or to COMMAND.
> The attached patch tries to clarify.

Thanks for improving that Bernhard.

It's generally easier to scan tables of values, than blocks of text.
How about we add the exit code table to the man page also?
I've adjusted your patch to do that (along with some other tweaks) in the attached.

cheers,
Pádraig

[timeout-exit-docs.patch (text/x-patch, attachment)]

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 14:38:06 +0200

Hi Padraig,

On 2020-06-07 14:13, Pádraig Brady wrote:
> How about we add the exit code table to the man page also?
> I've adjusted your patch to do that (along with some other tweaks) in the attached.

nice, especially also:

> -124 if @var{command} times out
> +124 if @var{command} times out, and @option{--preserve-status} is not specified

Minor, grammar-related question:

> +Upon timeout send the TERM signal to COMMAND, if no other SIGNAL specified.\n\
_______________^
s/timeout/&,/ ?

I stumbled upon this sentence a couple of times - shouldn't there be a comma?
The word 'timeout' could be a regular noun, a verb, or in this special case
the name of the tool, so I had to read the first half several times.
But maybe it's only me as a non-native English speaker - commas are much
cheaper over here. ;-)

Thanks & have a nice day,
Berny

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 14:39:35 +0200

On 2020-06-06 23:49, Jonny Grant wrote:
> Great patch.

thanks, Padraig meanwhile further improved it.

> How about writing signal 9 by the name, ie $ kill -s KILL
> likewise $ kill -s TERM

Where do you mean?

Have a nice day,
Berny

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 14:34:01 +0100

On 07/06/2020 13:38, Bernhard Voelker wrote:
> Minor, grammar-related question:
> 
>> +Upon timeout send the TERM signal to COMMAND, if no other SIGNAL specified.\n\
> _______________^
> s/timeout/&,/ ?
> 
> I stumbled upon this sentence a couple of times - shouldn't there be a comma?
> The word 'timeout' could be a regular noun, a verb, or in this special case
> the name of the tool, so I had to read the first half several times.
> But maybe it's only me as a non-native English speaker - commas are much
> cheaper over here. ;-)

When writing --help we tend to be space limited,
so I tend to write with punctuation mainly as disambiguation.
But indeed it is better to add the comma there, and we have space.

cheers,
Pádraig

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 15:45:27 +0200

On 2020-06-07 15:34, Pádraig Brady wrote:
> [...] it is better to add the comma there [...]

thanks, pushed with that change:
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=189776ff3b

Marking this as done.

Have a nice day,
Berny

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 7 Jun 2020 17:04:37 +0100

On 07/06/2020 13:39, Bernhard Voelker wrote:
> On 2020-06-06 23:49, Jonny Grant wrote:
>> Great patch.
> 
> thanks, Padraig meanwhile further improved it.
> 
>> How about writing signal 9 by the name, ie $ kill -s KILL
>> likewise $ kill -s TERM
> 
> Where do you mean?
> 
> Have a nice day,
> Berny
> 

Hi Berny

Sorry I was meaning to give an example of a shell command to send KILL, but maybe it's not necessary.

BTW, I saw the patch was applied. Great it's improved


I saw this new line is clearer:
"Upon timeout, send the TERM signal to COMMAND, if no other SIGNAL specified."

However, I thought even clearer is this variation :-
"Upon timeout, if no SIGNAL specified by --signal, send the TERM signal to COMMAND."

May I ask, do these texinfo changes also go into the man page?

This is the man page 8.32, and it doesn't match the html manual
https://www.man7.org/linux/man-pages/man1/timeout.1.html

I'm looking at the generated html manual:
https://www.gnu.org/software/coreutils/manual/coreutils.html#timeout-invocation

I don't know if these html pages can be updated to show the coreutil version on them at all at the top oand bottom?

Could an example be given on the man page and manual?

=======
EXAMPLE

The command below gives an example to demonstrate the use of this, sending HUP  signal after 5 seconds, and sending the 
KILL signal after 10 seconds if 'ls' has not finished.
    $ timeout -k 10s -s HUP 5s ls
=======


My last question

There is -k, it would be clearer if it was possible to specify -t or --timeout,
"$ timeout -k 11s 6s ls"   This always looks ambiguous to me, but the 11s is the KILL, and the 6s is the regular TERM 
signal.

Would you consider supporting a -t ?
So then we could write
"$ timeout -t 6s -k 11s ls"

or even
"$ timeout --timeout=6s --kill-after=11s ls"


Cheers
Jonny

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Mon, 15 Jun 2020 22:57:27 +0200

[Message part 1 (text/plain, inline)]

Hi Jonny,

On 2020-06-07 18:04, Jonny Grant wrote:
> Hi Berny
> 
> Sorry I was meaning to give an example of a shell command to send KILL, but maybe it's not necessary.
> 
> BTW, I saw the patch was applied. Great it's improved
> 
> 
> I saw this new line is clearer:
> "Upon timeout, send the TERM signal to COMMAND, if no other SIGNAL specified."
> 
> However, I thought even clearer is this variation :-
> "Upon timeout, if no SIGNAL specified by --signal, send the TERM signal to COMMAND."

IMO this is not really correct, as it states that a signal - TERM - is (only?)
sent in the case when --signal was not used, i.e., what happens in "else"?
It's hard to write short and precise man documentation.

> May I ask, do these texinfo changes also go into the man page?

No, at GNU coreutils (and lots of other GNU projects in general), we intend
to have small man pages, and leave the more detailed information in the
Texinfo manual:
  https://www.gnu.org/prep/standards/html_node/Man-Pages.html

Actually, the coreutils man pages are generated by running the tools with --help,
with some tiny information augmented where useful.

> This is the man page 8.32, and it doesn't match the html manual
> https://www.man7.org/linux/man-pages/man1/timeout.1.html

The man page project collects the latest version after a release.

> I'm looking at the generated html manual:
> https://www.gnu.org/software/coreutils/manual/coreutils.html#timeout-invocation

This belongs to the GNU coreutils project and will be updated with the
next release.

> I don't know if these html pages can be updated to show the coreutil version on them at all at the top oand bottom?

Hmm, in the HTML format, this is the first sentence after the table of contents:

  "This manual documents version 8.32 of the GNU core utilities, ..."

In the info reader (`info coreutils`), this is even the first sentence.
It's also on the title page of the generated PDF documentation.

> Could an example be given on the man page and manual?

As said, we wouldn't add such examples to the man page, I'm afraid ...

> =======
> EXAMPLE
> 
> The command below gives an example to demonstrate the use of this, sending HUP  signal after 5 seconds, and sending the 
> KILL signal after 10 seconds if 'ls' has not finished.
>      $ timeout -k 10s -s HUP 5s ls
> =======
... but for sure in the Texinfo manual.
The attached is an attempt to add some useful examples.

> My last question
> 
> There is -k, it would be clearer if it was possible to specify -t or --timeout,
> "$ timeout -k 11s 6s ls"   This always looks ambiguous to me, but the 11s is the KILL, and the 6s is the regular TERM 
> signal.
> 
> Would you consider supporting a -t ?
> So then we could write
> "$ timeout -t 6s -k 11s ls"
> 
> or even
> "$ timeout --timeout=6s --kill-after=11s ls"

While that would be possible, I'm not so excited about it.
The timeout value is a mandatory value similar to the perms for chmod(1),
and I've not seen any requests to support "chmod --mode=MODE FILE".

Have a nice day,
Berny

[0001-doc-add-timeout-examples.patch (text/x-patch, attachment)]

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sat, 4 Jul 2020 00:23:20 +0200

On 2020-06-15 22:57, Bernhard Voelker wrote:
> The attached is an attempt to add some useful examples.

There were no comments, so I pushed with a few tweaks:
  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=b1c6ef230c

Marking this as done.

Have a nice day,
Berny

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Fri, 3 Jul 2020 23:57:19 +0100

On 03/07/2020 23:23, Bernhard Voelker wrote:
> On 2020-06-15 22:57, Bernhard Voelker wrote:
>> The attached is an attempt to add some useful examples.
> 
> There were no comments, so I pushed with a few tweaks:
>   https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=b1c6ef230c
> 
> Marking this as done.
> 
> Have a nice day,
> Berny
> 

Hello Berny

Great you committed this.

May I ask if that exit status 137 could be clarified as 128+9, where 9 is the KILL signal number in this example please. I've pasted a patch below.

Another question, for me it wasn't clear that the "-k 3s" was cumulative with the duration 5, so the total being 8. I thought both durations both counted from when the command was invoked.

https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
‘-k duration’
‘--kill-after=duration’
Ensure the monitored command is killed by also sending a ‘KILL’ signal, after the specified duration. Without this option, if the selected signal proves not to be fatal, timeout does not kill the command.


Could this be clarified as "after the existing duration is added to this specified duration, cumulatively from when the command is invoked."? I can make another patch if this would be fine, and my understanding is correct.





From b029a83e4bb6f0d51a8f9eef90b5d46905f7ffc2 Mon Sep 17 00:00:00 2001
From: Jonny Grant <jg <at> jguk.org>
Date: Fri, 3 Jul 2020 23:51:15 +0100
Subject: [PATCH] Add an explanation of 137 to timeout example

Signed-off-by: Jonny Grant <jg <at> jguk.org>
---
 doc/coreutils.texi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index c072b1575..e89ce4d42 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -18178,6 +18178,7 @@ timeout -s INT 5s env --ignore-signal=INT sleep 20
 # Likewise, but sending the KILL signal 3 seconds after the initial
 # INT signal.  Hence, 'sleep' is forcefully terminated after about
 # 8 seconds (5+3), and 'timeout' returns with an exit status of 137.
+# The KILL signal number is 9, and 128+9 is 137
 timeout -s INT -k 3s 5s env --ignore-signal=INT sleep 20
 @end example
 
-- 
2.25.1

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 5 Jul 2020 01:25:25 +0200

[Message part 1 (text/plain, inline)]

On 2020-07-04 00:57, Jonny Grant wrote:
> May I ask if that exit status 137 could be clarified as 128+9, where 9 is
> the KILL signal number in this example please. I've pasted a patch below.

Thanks for the patch - this is always a great basis for discussions.

Well, this 128+9 arithmetic is explained just a couple of lines above,
i.e., where all the value for the exit status are described.
So adding it here again looks like repetition to me.

> Another question, for me it wasn't clear that the "-k 3s" was cumulative
> with the duration 5, so the total being 8. I thought both durations
> both counted from when the command was invoked.
> 
> https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
> ‘-k duration’
> ‘--kill-after=duration’
> Ensure the monitored command is killed by also sending a ‘KILL’ signal,
> after the specified duration. Without this option, if the selected signal
> proves not to be fatal, timeout does not kill the command.
> 
> Could this be clarified as "after the existing duration is added to
> this specified duration, cumulatively from when the command is invoked."?
> I can make another patch if this would be fine, and my understanding is correct.

Good catch, this is only documented in --help output (and therefore in timeout.1):

  -k, --kill-after=DURATION
                 also send a KILL signal if COMMAND is still running
                   this long after the initial signal was sent

What about the attached?

Thanks & have a nice day,
Berny

[0001-doc-clarify-timeout-k-behavior.patch (text/x-patch, attachment)]

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Sun, 5 Jul 2020 11:53:26 +0100

On 05/07/2020 00:25, Bernhard Voelker wrote:
> On 2020-07-04 00:57, Jonny Grant wrote:
>> May I ask if that exit status 137 could be clarified as 128+9, where 9 is
>> the KILL signal number in this example please. I've pasted a patch below.
> 
> Thanks for the patch - this is always a great basis for discussions.
> 
> Well, this 128+9 arithmetic is explained just a couple of lines above,
> i.e., where all the value for the exit status are described.
> So adding it here again looks like repetition to me.

Fair enough.

>> Another question, for me it wasn't clear that the "-k 3s" was cumulative
>> with the duration 5, so the total being 8. I thought both durations
>> both counted from when the command was invoked.
>>
>> https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
>> ‘-k duration’
>> ‘--kill-after=duration’
>> Ensure the monitored command is killed by also sending a ‘KILL’ signal,
>> after the specified duration. Without this option, if the selected signal
>> proves not to be fatal, timeout does not kill the command.
>>
>> Could this be clarified as "after the existing duration is added to
>> this specified duration, cumulatively from when the command is invoked."?
>> I can make another patch if this would be fine, and my understanding is correct.
> 
> Good catch, this is only documented in --help output (and therefore in timeout.1):
> 
>   -k, --kill-after=DURATION
>                  also send a KILL signal if COMMAND is still running
>                    this long after the initial signal was sent
> 
> What about the attached?
> 
> Thanks & have a nice day,
> Berny
> 

Hi Berny

Your patch looks great.

Is it worth clarifying that --kill-after=0s would send the KILL signal immediately after TERM?
$ timeout --kill-after=0s 2s du -h

Is it worth rejecting this? At the moment the -k is just ignored.
$ timeout -k 2s 0s du -h

Cheers
Jonny

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Wed, 15 Jul 2020 23:59:42 +0100

On 15/06/2020 21:57, Bernhard Voelker wrote:
> Hi Jonny,
> 
> On 2020-06-07 18:04, Jonny Grant wrote:
>> Hi Berny
>>
>> Sorry I was meaning to give an example of a shell command to send KILL, but maybe it's not necessary.
>>
>> BTW, I saw the patch was applied. Great it's improved
>>
>>
>> I saw this new line is clearer:
>> "Upon timeout, send the TERM signal to COMMAND, if no other SIGNAL specified."
>>
>> However, I thought even clearer is this variation :-
>> "Upon timeout, if no SIGNAL specified by --signal, send the TERM signal to COMMAND."
> 
> IMO this is not really correct, as it states that a signal - TERM - is (only?)
> sent in the case when --signal was not used, i.e., what happens in "else"?
> It's hard to write short and precise man documentation.
> 
>> May I ask, do these texinfo changes also go into the man page?
> 
> No, at GNU coreutils (and lots of other GNU projects in general), we intend
> to have small man pages, and leave the more detailed information in the
> Texinfo manual:
>   https://www.gnu.org/prep/standards/html_node/Man-Pages.html
> 
> Actually, the coreutils man pages are generated by running the tools with --help,
> with some tiny information augmented where useful.
> 
>> This is the man page 8.32, and it doesn't match the html manual
>> https://www.man7.org/linux/man-pages/man1/timeout.1.html
> 
> The man page project collects the latest version after a release.
> 
>> I'm looking at the generated html manual:
>> https://www.gnu.org/software/coreutils/manual/coreutils.html#timeout-invocation
> 
> This belongs to the GNU coreutils project and will be updated with the
> next release.
> 
>> I don't know if these html pages can be updated to show the coreutil version on them at all at the top oand bottom?
> 
> Hmm, in the HTML format, this is the first sentence after the table of contents:
> 
>   "This manual documents version 8.32 of the GNU core utilities, ..."

Hi Berny
Just to reply on this item.

Ah ok, on the HTML page that is still 12 pages after the first page. It would be nice to see it below the title? Before the TOC.
https://www.gnu.org/software/coreutils/manual/coreutils.html

I didn't search through for the version number, I missed it, as it wasn't at the top, or at the end.

Cheers, Jonny

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Mon, 20 Jul 2020 22:04:14 +0200

On 2020-07-05 12:53, Jonny Grant wrote:
> Your patch looks great.

Thanks, pushed (with the minor tweak mentioned below) at:
  https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=49bd08aea

> Is it worth clarifying that --kill-after=0s would send the KILL signal immediately after TERM?
> $ timeout --kill-after=0s 2s du -h

As the signal handler for the regular signal (TERM) does probably not have
enough time to do anything before being KILLed, this use case would better
be written as:

  $ timeout -s KILL 2s du -h

Not sure this is worth an extra explanation.

> Is it worth rejecting this? At the moment the -k is just ignored.
> $ timeout -k 2s 0s du -h

Hmm, rejecting is a bit harsh.  The question is if this is really
a problem for the users?  I mean once a user knows there is a -k
option, I would expect that she has read the documentation about
how to use it.
It is mentioned both in the Texinfo manual and in the --help output:

  A duration of 0 disables the associated timeout.

I squashed in the following little change:

  -This option has no effect if @command{timeout}'s duration is 0 and therefore
  +This option has no effect if @command{timeout}'s duration is 0 which
   disables the associated timeout.

Have a nice day,
Berny

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634-done <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Tue, 21 Jul 2020 16:53:53 +0100

On 20/07/2020 21:04, Bernhard Voelker wrote:
> On 2020-07-05 12:53, Jonny Grant wrote:
>> Your patch looks great.
> 
> Thanks, pushed (with the minor tweak mentioned below) at:
>   https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=49bd08aea
> 
>> Is it worth clarifying that --kill-after=0s would send the KILL signal immediately after TERM?
>> $ timeout --kill-after=0s 2s du -h
> 
> As the signal handler for the regular signal (TERM) does probably not have
> enough time to do anything before being KILLed, this use case would better
> be written as:
> 
>   $ timeout -s KILL 2s du -h
> 
> Not sure this is worth an extra explanation.
> 
>> Is it worth rejecting this? At the moment the -k is just ignored.
>> $ timeout -k 2s 0s du -h
> 
> Hmm, rejecting is a bit harsh.  The question is if this is really
> a problem for the users?  I mean once a user knows there is a -k
> option, I would expect that she has read the documentation about
> how to use it.
> It is mentioned both in the Texinfo manual and in the --help output:
> 
>   A duration of 0 disables the associated timeout.
> 
> I squashed in the following little change:
> 
>   -This option has no effect if @command{timeout}'s duration is 0 and therefore
>   +This option has no effect if @command{timeout}'s duration is 0 which
>    disables the associated timeout.
> 
> Have a nice day,
> Berny

Looks great!
Jonny

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>,
 Padraig Brady <pbrady <at> redhat.com>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Tue, 28 Jul 2020 23:38:16 +0200

[Message part 1 (text/plain, inline)]

On 2020-07-16 00:59, Jonny Grant wrote:
> On 15/06/2020 21:57, Bernhard Voelker wrote:
>> Hmm, in the HTML format, this is the first sentence after the table of contents:
>>
>>   "This manual documents version 8.32 of the GNU core utilities, ..."
> 
> Hi Berny
> Just to reply on this item.
> 
> Ah ok, on the HTML page that is still 12 pages after the first page. It would be nice to see it below the title? Before the TOC.
> https://www.gnu.org/software/coreutils/manual/coreutils.html
> 
> I didn't search through for the version number, I missed it, as it wasn't at the top, or at the end.

The attached adds the version to the title of the HTML manual.
E.g. grep also has it:
  https://www.gnu.org/software/grep/manual/html_node/index.html

@Padraig: okay to push?

Have a nice day,
Berny

[0001-doc-show-version-in-title-of-HTML-manual.patch (text/x-patch, attachment)]

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>, Jonny Grant <jg <at> jguk.org>,
 Andreas Schwab <schwab <at> linux-m68k.org>, Padraig Brady <pbrady <at> redhat.com>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Tue, 28 Jul 2020 22:53:57 +0100

On 28/07/2020 22:38, Bernhard Voelker wrote:
> On 2020-07-16 00:59, Jonny Grant wrote:
>> On 15/06/2020 21:57, Bernhard Voelker wrote:
>>> Hmm, in the HTML format, this is the first sentence after the table of contents:
>>>
>>>    "This manual documents version 8.32 of the GNU core utilities, ..."
>>
>> Hi Berny
>> Just to reply on this item.
>>
>> Ah ok, on the HTML page that is still 12 pages after the first page. It would be nice to see it below the title? Before the TOC.
>> https://www.gnu.org/software/coreutils/manual/coreutils.html
>>
>> I didn't search through for the version number, I missed it, as it wasn't at the top, or at the end.
> 
> The attached adds the version to the title of the HTML manual.
> E.g. grep also has it:
>    https://www.gnu.org/software/grep/manual/html_node/index.html
> 
> @Padraig: okay to push?

+1 thanks

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

From: Bernhard Voelker <mail <at> bernhard-voelker.de>
To: Pádraig Brady <P <at> draigBrady.com>,
 Jonny Grant <jg <at> jguk.org>, Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Wed, 29 Jul 2020 00:41:25 +0200

On 2020-07-28 23:53, Pádraig Brady wrote:
> +1 thanks

Thanks, pushed.

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

From: Jonny Grant <jg <at> jguk.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>,
 Pádraig Brady <P <at> draigBrady.com>,
 Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 41634 <at> debbugs.gnu.org
Subject: Re: bug#41634: 'timeout' returning 124 and 133
Date: Wed, 29 Jul 2020 13:19:15 +0100

On 28/07/2020 23:41, Bernhard Voelker wrote:
> On 2020-07-28 23:53, Pádraig Brady wrote:
>> +1 thanks
> 
> Thanks, pushed.
> 

Great!

Previous Next

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