[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21760: timeout: Feature Request: --verbose ==> output if timeout
From: |
Pádraig Brady |
Subject: |
bug#21760: timeout: Feature Request: --verbose ==> output if timeout |
Date: |
Tue, 3 Oct 2017 23:36:57 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 02/10/17 07:04, Ian Jackson wrote:
> I have to say that I find this bug thread quite perplexing.
>
> It is completely normal for a GNU/Unix command line utility to print a
> message to stderr in error cases. Almost every program that exits
> nonzero prints a message to stderr.
>
> The normal convention in shell scripts (and other contexts where
> commands are invoked) is to:
> * use the exit status to decide whether to continue executing
> * rely on the failing command to print a message to the script's
> stderr
>
> The stderr error message from a failing command appears on the user's
> terminal in a script run interactively; it appears in emailed logs
> from cron; it can appear in logfiles; etc.
>
> When I first discovered that GNU timeout(1) does not print an error
> message when the timeout occurs, I was astonished. IMO that ought to
> have been the default behaviour. Unfortunately that is too late to
> fix now but we should at least have a one-letter option to request
> behaviour compatible with normal shell programming conventions.
>
>
> The alternative is that at most times when use of timeout is added to
> some program or config file, the programmer/administrator will have to
> write a clumsy shell circumlocution to arrange that an appropriate
> message is sent to stderr.
>
> These runic shell circumlocutions will proliferate. They will have
> bugs. The bugs will propagate by cut-and-paste, followed by fixes for
> the bugs. Everyone's commands will become verbose and hard to
> understand.
>
> All of this could be prevented by simply providing a way to make
> timeout print a message to stderr.
>
>
> I guess I need to dispose of some the potential problems which have
> been advanced as counterarguments, even though to my mind they are
> extremely weak.
>
> A key observation I would make is that the arguments against
> timeout(1) printing a message are fully general counterarguments
> against _any_ program printing _any_ error message. Surely that shows
> that they can't be right.
>
>> For example I don't like the N seconds, or N.012 more detailed
>> output. As soon as this is produced there will be other people
>> trying to parse it.
>
> Most of the people who are asking for this feature don't care exactly
> what the message is. It should mention the program which was invoked
> and the fact that there was a timeout. The exact format is
> immaterial.
>
> The purpose is not for it to be parsed, but for it to be read by
> humans who are trying to debug something. This is generally true of
> error messages.
>
> If anyone complains that they are trying to parse this error message
> you can tell them not to be so silly. There will be many fewer of
> those than there will be people inconvenienced by the lack of a
> message at all.
>
> Likewise, if someone sends a patch to add more information to the
> message, that is not a problem. You can just accept it, or not, as
> you like.
>
>> BTW: timeout shares stdout/stderr with its child; therefore,
>> wouldn't the interleaved output be problematic?
>
> No. The purpose is precisely to have the error report from timeout(1)
> to go to the same place as errors from the command are reported.
>
> This is not a problem with any other adverbial command, of which there
> are very many nowadays. See for example xargs, fakeroot, faketime,
> authbind, etc. etc.
>
>> A good example of a possible problem due to the law of unintended
>> consequences.
>
> How bogglesome. This "interleaving" is precisely the intended
> consequence. (Actually, what will normally happen is that the message
> from timeout will follow all of the program's output.)
>
>> And if this leads to the request for --output-fd=N to
>> reroute file descriptors just to work around it then that is much too
>> much and shouldn't be done.
>
> Other adverbial commands have not had such requests and in general I
> agree that they should be rejected. If this is a problem then a shell
> rune can be used to replumb the fds.
>
> That is a hypothetical timeout -v --output-fd=42 blah blah
> can be replaced with
> timeout 3>&2 2>&42 -v sh -ec 'exec 2>&3 3>&- "$@"' x blah blah
> (assuming fd 3 is not used for something else in $@). This is
> a fully general technique which can be deployed to implement any
> such minority use case.
>
>
> The main point is that "want it to print an error message if there is
> an error" is not a minority use case.
Thanks for detailing your arguments, and +2 for the phrase:
"runic shell circumlocutions will proliferate" :)
A reason we don't output a message by default is that
timeout(1) could be used to run a process which runs
for an indeterminate amount of time like:
timeout --preserve-status 1d ./simulation
Whether we support `timeout --verbose` is one of those marginal cases.
Using shell works with all versions of timeout, but it's not
trivial due to differing exit status. For example if a SIGKILL was sent
most shells return 137, while ksh returns 265.
I agree with you that the stderr interleaving is probably not a practical issue.
So I'm leaning towards supporting --verbose which would output something like:
timeout: aborting command 'blah' with signal SIGTERM
timeout: aborting command 'blah' with signal SIGKILL
cheers,
Pádraig