[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7317: Bug in SLEEP command
From: |
Андрей Передрий |
Subject: |
bug#7317: Bug in SLEEP command |
Date: |
Tue, 02 Nov 2010 19:41:52 +0200 |
> 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
> > address@hidden ~]# sleep 36500d ; date
> > Sat Oct 30 10:38:44 EEST 2010
> > address@hidden ~]#
> >
> > 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.
uname -a
Linux ************* 2.6.9-89.0.23.ELsmp #1 SMP Wed Mar 17 06:55:21 EDT 2010
i686 athlon i386 GNU/Linux
cat /etc/redhat-release
CentOS release 4.8 (Final)
--
A.P.
bug#7317: Bug in SLEEP command, Pádraig Brady, 2010/11/02
bug#7317: Bug in SLEEP command,
Андрей Передрий <=