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
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?
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
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
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
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
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
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 .
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
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
10 matches
Mail list logo
