bug#21760: timeout: Feature Request: --verbose ==> output if timeout

[Pádraig Brady]

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