bug#7317: Bug in SLEEP command

[Андрей Передрий]

> On 03/11/10 12:41, Jim Meyering wrote:
> > P?draig Brady wrote:
> >> On 02/11/10 16:41, Eric Blake wrote:
> >>> On 11/02/2010 09:46 AM, Андрей Передрий wrote:
> >>>>
> >>>> Hello guys!
> >>>>
> >>>> I found a bug in 'sleep' command.
> >>>
> >>>> 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
> >>>
> >>> Is your system 32-bit or 64-bit? It makes a difference in determining
> >>> whether there is a bug in the OS sleep primitives (for example, we know
> >>> that 64-bit Linux has a bug where nanosleep with an extremely large
> >>> value will cause the kernel to overflow and sleep for the wrong amount
> >>> of time, but coreutils has workarounds in place for that).
> >>
> >> I had a quick look at the gnulib replacement which
> >> seems to assume 49 days is the worst case,
> >> whereas we now need to use 24 days?
> > 
> > Sounds reasonable. It'd be good to document which kernel(s) are affected.
> > Have you reproduced it? (i.e., in a VM, changing the date, if that is 
> > sufficient)
> > 
> 
> The only mention in the gnulib nanosleep docs about linux is:
> 
> "This function mishandles large arguments when interrupted by
> a signal on some platforms: Linux 64-bit, Solaris 64-bit."
> 
> This may or may not be related to:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1711ef38
> 
> So the OPs case seems different I think in that he's using 32 bit
> on RHEL & Centos 4.6 & 4.8 with 2.6.9-89.0.23.ELsmp
> 
> I'm not sure if setting the date is enough.
> I tried on my 2.6.30 32bit laptop with no issue.
> Андрей did you set the date, or did you really wait 24 days :)

I really wait 24 days :)
I used command "sleep 36500d" in my script for infinite loop organization.
I tested this 2 times in RHEL4.6 in real (non virtualized) environment.
And 1 time in Centos48 (in real env)
So I found this bug firstly 49 days ago :)
 

--
A.P.