Hi,

timeout should (optionally) emit an error message when the timeout is
reached. This would make debugging a range of issues easier, but my
case in point is ceph, which has, in a service file:

ExecStart=/bin/sh -c 'timeout 120 flock /var/lock/ceph-disk-$(basename
%f) /usr/sbin/ceph-disk --verbose --log-stdout trigger --sync %f'

Currently nothing is logged when this timeout is reached, which made
debugging a startup issue needlessly fiddly. It would be good to have
an option (e.g. --log-on-exit or --verbose or somesuch) which would
make timeout say something like "timeout elapsed, killing ...".

Thanks,

Matthew

Try
ExecStart=/bin/sh -c 'timeout 120 flock /var/lock/ceph-disk-$(basename %f) /usr/sbin/ceph-disk --verbose --log-stdout trigger --sync %f ; RET=$? ; if [ $RET -eq 124 ] ; then echo "Timed out!" ; fi ; return $RET'

Mike Stone

Well, yes, one can write wrappers around anything. That doesn't mean it
wouldn't be useful if timeout had an option to emit the obviously-useful
message itself.

Regards,

Matthew

Michael Stone:

It's nice to provide a workaround, and that's helpful to other people
reading this bug.  But I don't think that's really an answer to
Matthew's request that timeout should have this as a built-in option.

In most situations where timeout is invoked, the overall situation is
one where a message should be reported to stderr.  Some but by no
means all call sites will already have some mechanism to report the
value of a non-zero exit status, but printing something about status
124 is not really helpful to the person reading the stderr output.

So that means that most call sites, there would have to be special
logic to notice the exit status 124 and do something special with it.

And of course timeout(1) is a command line utility which is intended
to be useable as an adverbial command for other programs.  So this
means that in most cases when timeout is used, it needs to be wrapped
up with some shell rune such as you suggest.

Having every person who decides to use timeout write a shell rune like
this is not very sensible.  The runes will proliferate; they will have
bugs (for example, your suggestion smashes the exit status with zero);
and it is just a lot of extra work.

It would be much better if this were done centrally in timeout(1),
where it is straightforward.

Ian.

It should grab the original exit status and then propagate it, no?

Mike Stone

Mike Stone:
IMO poor practice).

But it has another bug: it prints the message to stdout, not stderr.
Of course that may not matter in this context (I don't know exactly
how systemd treats that line) but because of the lack of a suitable
option people will clone-and-hack these runes.

Do you agree that these ad-hoc runes are a bad thing and it would be
better to have an official built-in way to do this ?

Ian.

Well, the more general answer is that I'm not going to introduce a
debian-specific patch to change the behavior of timeout. coreutils
upstream tends to see debian bug reports and can chime in on whether
this is something that would be accepted there. Whether or not that
happens, I offered a suggestion to address the immediate concern raised
which can be ignored if desired.

I personally have an easier time coming up with use cases where I'd want
the return code to initiate further logic than cases where just printing
a message and doing nothing else is useful, but that's neither here nor
there.

Mike Stone

Except, of course, if you need to muck about with return codes, no? I
think it would be pretty silly to set a oneliner whose whole purpose is
to check and pass on an error code to abort on error.

I guess that really depends on whether you want the message on stderr vs
stdout. Since I don't really know what would be useful in this context I
picked the one with less words. It's pretty straightforward to change
that if desired, but that level of flexibility to tailor the solution to
exactly what's needed is what's so great!

No, but if upstream likes it that doesn't really matter. :)

Mike Stone

Michael Stone writes ("Re: Bug#877174: coreutils: timeout should (optionally) emit an error message when timeout reached"):
...

I guess you mean you _don't_ like these ad-hoc runes.  In which case
maybe you'd like to chime in here...

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21760

No, I do think that adding a timeout flag is silly, and inconsistent
with the implementation on other platforms.

Mike Stone