[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: |
Thu, 23 Nov 2017 14:35:44 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 |
On 03/10/17 23:36, Pádraig Brady wrote:
> 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
Handled in the attached.
Marking this as done.
cheers,
Pádraig
timeout--verbose.patch
Description: Text Data
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout,
Pádraig Brady <=
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Jim Meyering, 2017/11/23
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Pádraig Brady, 2017/11/23
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Bernhard Voelker, 2017/11/27
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Pádraig Brady, 2017/11/27
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Bernhard Voelker, 2017/11/27
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Pádraig Brady, 2017/11/28
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Bernhard Voelker, 2017/11/28
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Pádraig Brady, 2017/11/29
- bug#21760: timeout: Feature Request: --verbose ==> output if timeout, Bernhard Voelker, 2017/11/29