GNU bug report logs - #7317
Bug in SLEEP command

Previous Next

Package: coreutils;

Reported by: Андрей Передрий <andi <at> ukr.net>

Date: Tue, 2 Nov 2010 15:46:02 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Андрей Передрий <andi <at> ukr.net>
Cc: 7317 <at> debbugs.gnu.org
Subject: bug#7317: Bug in SLEEP command
Date: Tue, 02 Nov 2010 16:59:23 +0000
On 02/11/10 15:46, Андрей Передрий wrote:
> 
> Hello guys!
> 
> I found a bug in 'sleep' command.
> Please see below:
> 
> # date
> Tue Oct  5 14:12:11 EEST 2010
> [root <at> gate ~]# sleep 36500d ; date
> Sat Oct 30 10:38:44 EEST 2010
> [root <at> gate ~]#
> 
> As you can see - 'sleep' was terminated by himself after 24 days, 20 hours, 26 minutes and 33 seconds.
> 24*24*3600 + 20*3600 + 26*60 + 33 = 2073600 + 72000 + 1560 + 33 = 2147193 seconds
> It seems like overflow.
> coreutils 6.10-6
> Debian 5.0.6  

eek!
That's lenny right, with kernel 2.6.32 or so.

POSIX says that we should support 2147483647 seconds at least.
We could make multiple calls to xnanosleep if the param is
greater than that, but do we really need to support > 68 years.
Currently we silently truncate to this limit.

Anyway could you send the output of: strace sleep 36500d

On 64 bit lenny here I get: nanosleep({3153600000, 0},
On 32 bit Fedora 11 I get:  nanosleep({2147483647, 999999999}

If you get a large value being passed down,
then it suggests an issue with glibc/kernel?

cheers,
Pádraig.




This bug report was last modified 14 years and 251 days ago.

Previous Next


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