emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#21760: closed (timeout: Feature Request: --verbose


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#21760: closed (timeout: Feature Request: --verbose ==> output if timeout was reached)
Date: Thu, 23 Nov 2017 22:36:02 +0000

Your message dated Thu, 23 Nov 2017 14:35:44 -0800
with message-id <address@hidden>
and subject line Re: bug#21760: timeout: Feature Request: --verbose ==> output 
if timeout
has caused the debbugs.gnu.org bug report #21760,
regarding timeout: Feature Request: --verbose ==> output if timeout was reached
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
21760: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21760
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: timeout: Feature Request: --verbose ==> output if timeout was reached Date: Mon, 26 Oct 2015 11:30:36 +0100 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
About commandline tool "timeout": Start COMMAND, and kill it if still running 
after DURATION.

A new team mate wasted some time to debug why
a process was killed with signal 15.

I think it would be nice to have an --verbose option, and a some
text which explains why the signal was send.

This is important in environments where the one who reads
the script failures is not the same person who writes the script.

What do you think?

Example:

Old:

  address@hidden:~$ timeout 1s ping localhost
  PING localhost (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms

New:

  address@hidden:~$ timeout 1s ping localhost
  PING localhost (127.0.0.1) 56(84) bytes of data.
  64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.078 ms
  ** Process "ping localhost" was killed with signal 16 since the timeout of 1s 
was reached. **



--
Thomas Guettler http://www.thomas-guettler.de/



--- End Message ---
--- Begin Message --- Subject: Re: 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

Attachment: timeout--verbose.patch
Description: Text Data


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]