GNU bug report logs - #7359
sleep 9999999999

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 7359 in the body.
You can then email your comments to 7359 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: Matthew Bachmann <matt <at> itasoftware.com>
To: bug-coreutils <at> gnu.org
Subject: sleep 9999999999
Date: Tue, 9 Nov 2010 14:31:42 -0500

sleep called with very big numbers returns immediately with success

-Matt

matt <at> ita1bbx40,d1r17733u07 | date; sleep 9999999999 && echo success; date; sleep --version
Tue Nov  9 14:31:04 EST 2010
success
Tue Nov  9 14:31:04 EST 2010
sleep (GNU coreutils) 5.97
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software.  You may redistribute copies of it under the terms of
the GNU General Public License <http://www.gnu.org/licenses/gpl.html>.
There is NO WARRANTY, to the extent permitted by law.

Written by Jim Meyering and Paul Eggert.
matt <at> ita1bbx40,d1r17733u07 | 

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

From: Eric Blake <eblake <at> redhat.com>
To: Matthew Bachmann <matt <at> itasoftware.com>
Cc: 7359 <at> debbugs.gnu.org
Subject: Re: bug#7359: sleep 9999999999
Date: Tue, 09 Nov 2010 13:27:44 -0700

[Message part 1 (text/plain, inline)]

On 11/09/2010 12:31 PM, Matthew Bachmann wrote:
> sleep called with very big numbers returns immediately with success
> 
> -Matt
> 
> matt <at> ita1bbx40,d1r17733u07 | date; sleep 9999999999 && echo success; date; sleep --version
> Tue Nov  9 14:31:04 EST 2010
> success
> Tue Nov  9 14:31:04 EST 2010
> sleep (GNU coreutils) 5.97

That's rather old.  Can you repeat it with the latest stable release of
8.6?  Meanwhile, I'm wondering if your setup is a duplicate of this report:
http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00011.html

although it's hard to say, since you didn't provide any information
about what platform and kernel version you tested on.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Matthew Bachmann <matt <at> itasoftware.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7359 <at> debbugs.gnu.org
Subject: Re: bug#7359: sleep 9999999999
Date: Tue, 9 Nov 2010 15:31:31 -0500

Here's what I'm running:

matt <at> ita1bbx40,d1r17733u07 | uname -a
Linux ita1bbx40 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
matt <at> ita1bbx40,d1r17733u07 | cat /etc/issue
CentOS release 5.3 (Final)
Kernel \r on an \m

matt <at> ita1bbx40,d1r17733u07 | 

I'm in a large shared environment where I can't upgrade sleep.  I just wanted to bring this to your attention, I can work around and don't need a fix.  Thanks.

-Matt

On Nov 9, 2010, at 3:27 PM, Eric Blake wrote:

> On 11/09/2010 12:31 PM, Matthew Bachmann wrote:
>> sleep called with very big numbers returns immediately with success
>> 
>> -Matt
>> 
>> matt <at> ita1bbx40,d1r17733u07 | date; sleep 9999999999 && echo success; date; sleep --version
>> Tue Nov  9 14:31:04 EST 2010
>> success
>> Tue Nov  9 14:31:04 EST 2010
>> sleep (GNU coreutils) 5.97
> 
> That's rather old.  Can you repeat it with the latest stable release of
> 8.6?  Meanwhile, I'm wondering if your setup is a duplicate of this report:
> http://lists.gnu.org/archive/html/bug-coreutils/2010-11/msg00011.html
> 
> although it's hard to say, since you didn't provide any information
> about what platform and kernel version you tested on.
> 
> -- 
> Eric Blake   eblake <at> redhat.com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> 

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Matthew Bachmann <matt <at> itasoftware.com>
Cc: 7359 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7359: sleep 9999999999
Date: Tue, 09 Nov 2010 22:33:11 +0000

On 09/11/10 20:31, Matthew Bachmann wrote:
> Here's what I'm running:
> 
> matt <at> ita1bbx40,d1r17733u07 | uname -a
> Linux ita1bbx40 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
> matt <at> ita1bbx40,d1r17733u07 | cat /etc/issue
> CentOS release 5.3 (Final)
> Kernel \r on an \m
> 
> matt <at> ita1bbx40,d1r17733u07 | 
> 
> I'm in a large shared environment where I can't upgrade sleep.  I just wanted to bring this to your attention, I can work around and don't need a fix.  Thanks.

If you had a compiler, then doing the following would
help us eliminate already handled issues:

  wget http://ftp.gnu.org/pub/gnu/coreutils/coreutils-8.6.tar.gz
  gzip -dc coreutils-8.6.tar.gz | tar -x
  cd coreutils-8.6
  ./configure --quiet && make
  strace -e nanosleep src/sleep 9999999999

If not then an strace of the existing binary would help

  strace -e nanosleep sleep 9999999999

I tried the command on 32 bit FC5 (coreutils-5.97, kernel-2.6.17) without issue.

cheers,
Pádraig.

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

From: Matthew Bachmann <matt <at> itasoftware.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 7359 <at> debbugs.gnu.org, Eric Blake <eblake <at> redhat.com>
Subject: Re: bug#7359: sleep 9999999999
Date: Wed, 10 Nov 2010 13:20:16 -0500

Existing stuff:

matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep sleep 9999999999
nanosleep({9999999999, 0}, NULL)        = 0
matt <at> ita1bbx40,d1r17733u07 | rpm -qa | grep coreutils
policycoreutils-1.33.12-14.2.el5
coreutils-5.97-19.el5

With download you pointed me at:

matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep src/sleep 9999999999
nanosleep({4233600, 0},  <unfinished ...>
matt <at> ita1bbx40,d1r17733u07 | 

I ctrl-c'ed it because it appeared to be actually sleeping instead of returning immediately.  So yeah, it looks like it works fine with newer stuff.

-Matt

On Nov 9, 2010, at 5:33 PM, Pádraig Brady wrote:

> On 09/11/10 20:31, Matthew Bachmann wrote:
>> Here's what I'm running:
>> 
>> matt <at> ita1bbx40,d1r17733u07 | uname -a
>> Linux ita1bbx40 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
>> matt <at> ita1bbx40,d1r17733u07 | cat /etc/issue
>> CentOS release 5.3 (Final)
>> Kernel \r on an \m
>> 
>> matt <at> ita1bbx40,d1r17733u07 | 
>> 
>> I'm in a large shared environment where I can't upgrade sleep.  I just wanted to bring this to your attention, I can work around and don't need a fix.  Thanks.
> 
> If you had a compiler, then doing the following would
> help us eliminate already handled issues:
> 
>  wget http://ftp.gnu.org/pub/gnu/coreutils/coreutils-8.6.tar.gz
>  gzip -dc coreutils-8.6.tar.gz | tar -x
>  cd coreutils-8.6
>  ./configure --quiet && make
>  strace -e nanosleep src/sleep 9999999999
> 
> If not then an strace of the existing binary would help
> 
>  strace -e nanosleep sleep 9999999999
> 
> I tried the command on 32 bit FC5 (coreutils-5.97, kernel-2.6.17) without issue.
> 
> cheers,
> Pádraig.

Message #22 received at 7359-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Matthew Bachmann <matt <at> itasoftware.com>
Cc: Eric Blake <eblake <at> redhat.com>, 7359-done <at> debbugs.gnu.org
Subject: Re: bug#7359: sleep 9999999999
Date: Wed, 10 Nov 2010 22:30:49 +0000

On 10/11/10 18:20, Matthew Bachmann wrote:
> Existing stuff:
> 
> matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep sleep 9999999999
> nanosleep({9999999999, 0}, NULL)        = 0
> matt <at> ita1bbx40,d1r17733u07 | rpm -qa | grep coreutils
> policycoreutils-1.33.12-14.2.el5
> coreutils-5.97-19.el5
> 
> With download you pointed me at:
> 
> matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep src/sleep 9999999999
> nanosleep({4233600, 0},  <unfinished ...>
> matt <at> ita1bbx40,d1r17733u07 | 
> 
> I ctrl-c'ed it because it appeared to be actually sleeping instead of returning immediately.  So yeah, it looks like it works fine with newer stuff.

Right, that confirms that it's sleeping for 49 days at a time.
I.E. the existing immediately detectable workaround is in place.

cheers,
Pádraig.

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

From: Michal Svoboda <pht <at> spatium.org>
To: 7359 <at> debbugs.gnu.org, P <at> draigBrady.com
Subject: Re: bug#7359: sleep 9999999999
Date: Thu, 11 Nov 2010 08:21:17 +0100

Pádraig Brady wrote:
> > matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep sleep 9999999999
> > nanosleep({9999999999, 0}, NULL)        = 0

Just out of curiosity, what's wrong with nanosleep({9999999999, 0} ?

The first argument should be time_t, which should not be prone to
something stupid like overflowing at 2 (or 4) billion or so.

Michal Svoboda

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

From: Pádraig Brady <P <at> draigBrady.com>
To: 7359 <at> debbugs.gnu.org
Subject: Re: bug#7359: sleep 9999999999
Date: Thu, 11 Nov 2010 08:13:21 +0000

On 11/11/10 07:21, Michal Svoboda wrote:
> Pádraig Brady wrote:
>>> matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep sleep 9999999999
>>> nanosleep({9999999999, 0}, NULL)        = 0
> 
> Just out of curiosity, what's wrong with nanosleep({9999999999, 0} ?
> 
> The first argument should be time_t, which should not be prone to
> something stupid like overflowing at 2 (or 4) billion or so.

Nothing is wrong with it, except that it trips
up that old 64 bit linux kernel.

cheers,
Pádraig.

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

From: Eric Blake <eblake <at> redhat.com>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 7359 <at> debbugs.gnu.org
Subject: Re: bug#7359: sleep 9999999999
Date: Thu, 11 Nov 2010 08:12:32 -0700

[Message part 1 (text/plain, inline)]

On 11/11/2010 01:13 AM, Pádraig Brady wrote:
> On 11/11/10 07:21, Michal Svoboda wrote:
>> Pádraig Brady wrote:
>>>> matt <at> ita1bbx40,d1r17733u07 | strace -e nanosleep sleep 9999999999
>>>> nanosleep({9999999999, 0}, NULL)        = 0
>>
>> Just out of curiosity, what's wrong with nanosleep({9999999999, 0} ?
>>
>> The first argument should be time_t, which should not be prone to
>> something stupid like overflowing at 2 (or 4) billion or so.
> 
> Nothing is wrong with it, except that it trips
> up that old 64 bit linux kernel.

To be more precise - that kernel has a bug with nanosleep(-1,NULL).  So
we replace it with a working nanosleep.  However, Windows machines have
a bug with nanosleep(60*60*24*50,NULL), so we replace nanosleep on that
platform as well.  It's easier to have a single nanosleep replacement
for both platforms; therefore, our nanosleep replacement repeatedly
rolls over every 49 days, due to the worst case system we are replacing,
even if the Linux replacement could go the full 9999999999 seconds
without overflow.

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

Previous Next

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