GNU bug report logs - #32521
coreutils timeout in a bash script not transparent for the application

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 32521 in the body.
You can then email your comments to 32521 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Rafal Jankowski" <jankowsr <at> oceanic.wsisiz.edu.pl>
To: bug-coreutils <at> gnu.org
Subject: coreutils timeout in a bash script not transparent for the application
Date: Fri, 24 Aug 2018 20:19:27 +0200

Dear coreutils users/developers

https://stackoverflow.com/questions/52008104/coreutils-timeout-in-a-bash-script-not-transparent-for-the-application

I have not done enough investigation to claim this is a true timeout bug
but I'm wondering if you could advise on this issue?

Regards,
Rafał

Message #8 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Rafal Jankowski <jankowsr <at> oceanic.wsisiz.edu.pl>, 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent for
 the application
Date: Fri, 24 Aug 2018 13:04:20 -0700

Rafal Jankowski wrote:
> https://stackoverflow.com/questions/52008104/coreutils-timeout-in-a-bash-script-not-transparent-for-the-application
> 
> I have not done enough investigation to claim this is a true timeout bug
> but I'm wondering if you could advise on this issue?

I can't reproduce the bug on Fedora 28. I don't have fabric.api installed, but 
when my Python program looked like this:

#!/usr/bin/python
import time
time.sleep (20)

the output of the script was RETCODE=124 as expected, and when the Python 
program looked like this:

#!/usr/bin/python
import time
time.sleep (5)

the exit status was 0 as expected.

Perhaps the problem is within fabric.api.

Message #11 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: "Rafal Jankowski" <jankowsr <at> oceanic.wsisiz.edu.pl>
To: 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent
 for the application
Date: Fri, 24 Aug 2018 22:23:21 +0200

Hi Paul,

[...]
> I can't reproduce the bug on Fedora 28. I don't have fabric.api installed,
> but
> when my Python program looked like this:
>
> #!/usr/bin/python
> import time
> time.sleep (20)
>
> the output of the script was RETCODE=124 as expected, and when the Python
> program looked like this:
>
> #!/usr/bin/python
> import time
> time.sleep (5)
>
> the exit status was 0 as expected.
>
> Perhaps the problem is within fabric.api.


The type of application matters (as I mentioned at the beginning this is
not reproducible with fabric 2). So I agree this is somehow specific to
fabric.api. However to my understanding timeout should be as transparent
as possible for the application that is being executed. So if we can
observe that kind of issue with any application I would rather tend to
think it's more timeout issue than the app issue.

Message #14 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Rafal Jankowski <jankowsr <at> oceanic.wsisiz.edu.pl>, 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent for
 the application
Date: Fri, 24 Aug 2018 13:58:25 -0700

Rafal Jankowski wrote:
> my understanding timeout should be as transparent
> as possible for the application that is being executed

Sure, but no matter what 'timeout' does, it cannot possibly be transparent to 
every application, because that application might be using the same mechanism 
that 'timeout' is using. Until we know more about exactly what the application 
is up to, it's not clear that this is a bug in 'timeout'.

Message #17 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: Rafal Jankowski <jankowsr <at> oceanic.wsisiz.edu.pl>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent
 for the application
Date: Sat, 25 Aug 2018 08:14:22 +0200 (CEST)

On Fri, 24 Aug 2018, Paul Eggert wrote:

> Sure, but no matter what 'timeout' does, it cannot possibly be transparent to 
> every application, because that application might be using the same mechanism 
> that 'timeout' is using. Until we know more about exactly what the 
> application is up to, it's not clear that this is a bug in 'timeout'.

Ah, OK. I noticed a note in the 'info timeout' regarding special utilities 
that may not work with timeout. So that may be a similar case. If it's not 
too much effort could you please briefly explain or point to existing 
documentation what kind of mechanism can cause any kind of misbehaviour 
for the application?

Also what is quite eye-spotting to me is the fact that:
timeout [time] app  #works fine
app invoked from the bash script # works fine
timeout [time] app invoked from the bash script # does not work

Message #20 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Rafal Jankowski <jankowsr <at> oceanic.wsisiz.edu.pl>
Cc: 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent for
 the application
Date: Sat, 25 Aug 2018 00:08:11 -0700

Rafal Jankowski wrote:
> If it's not too much effort could you please briefly explain or point to 
> existing documentation what kind of mechanism can cause any kind of misbehaviour 
> for the application?

Sorry, don't know. You'll have to look at the source code, I expect. Or try 
running 'strace -f' for hints.

Message #23 received at 32521 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Rafal Jankowski <jankowsr <at> oceanic.wsisiz.edu.pl>, 32521 <at> debbugs.gnu.org
Subject: Re: bug#32521: coreutils timeout in a bash script not transparent for
 the application
Date: Sun, 26 Aug 2018 12:54:30 -0700

tag 32521 notabug
close 32521
stop

On 24/08/18 11:19, Rafal Jankowski wrote:
> Dear coreutils users/developers
> 
> https://stackoverflow.com/questions/52008104/coreutils-timeout-in-a-bash-script-not-transparent-for-the-application
> 
> I have not done enough investigation to claim this is a true timeout bug
> but I'm wondering if you could advise on this issue?

It seems that both timeout(1) and fabric are acting as monitors,
and fabric < 2 is not general enough to handle that.
You could simplify some of timeout's monitoring duties,
so that it runs more like a normal command
by using the --foreground option.

Given this is not an issue with Fabric 2,
I'm closing this for now.

cheers,
Pádraig

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.