Bug 31200 - sleep() returns too soon sometimes
sleep() returns too soon sometimes
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-09 14:19 EST by j. alan eldridge
Modified: 2016-11-24 10:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-09 14:19:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description j. alan eldridge 2001-03-09 14:19:19 EST
the sleep(3) call takes a number of seconds. if it returns 0, it has slept
at least that many seconds. if it returns n > 0, you need to sleep n more
seconds to reach your desired sleep time.

testing a bug in vixie-cron (fixed) i found cases where sleep violates this
interface. sometimes it will return a tiny bit too soon.

no clock changes were made during the test which produced the output below.

this output from a debugging version of vixie-cron-3.0.1-61 will show the
errant behavior:

[14313] cron_sleep start at 984153660
[14313] TargetTime=984153720, sec-to-wait=60
[14313] TargetTime=984153720, sec-to-wait=60
[14313] sleeping for 60 seconds
log_it: (root 14731) CMD (run-parts /etc/cron.hourly)
log_it: (alane 14732) CMD (/home/alane/bin/backup-file -d
misc/web/bookmarks misc/web/bookmarks.html)
[14313] sleep(60 seconds) returned 59
[14313] sleeping for 59 seconds
[14313] sleep(59 seconds) returned 0
[14313] cron_sleep leave at 984153719

directly above we see the bug: 

time is 984153660
sleep(60) returns 59
sleep(59) returns 0
time is 984153719

oops, only 59 seconds have elapsed. 

[14313] tick(2,11,8,2,5)
[14313] cron_sleep start at 984153719
[14313] TargetTime=984153720, sec-to-wait=1
[14313] TargetTime=984153720, sec-to-wait=1
[14313] sleeping for 1 seconds
log_it: (alane 14777) CMD (/home/alane/bin/killjunk /home/alane)
[14313] sleep(1 seconds) returned 1
[14313] sleeping for 1 seconds
[14313] sleep(1 seconds) returned 0
[14313] cron_sleep leave at 984153721

you can see above how this triggers a bug in the cron code, causing it to
execute the same command twice. the cron issue is resolved.
Comment 1 Jakub Jelinek 2001-03-12 12:04:15 EST
See info libc, section Sleeping:
   Resist the temptation to implement a sleep for a fixed amount of
time by using the return value of `sleep', when nonzero, to call
`sleep' again.  This will work with a certain amount of accuracy as
long as signals arrive infrequently.  But each signal can cause the
eventual wakeup time to be off by an additional second or so.  Suppose a
few signals happen to arrive in rapid succession by bad luck--there is
no limit on how much this could shorten or lengthen the wait.

I don't think sleep violated anything, it guarantees you that if it returns 0,
it has slept for at least the specified number of seconds, there is nothing
in either of POSIX, Unix98 or sleep man pages which would tell you anything
about the accumulated time of a series of sleep(3) passing its return values
to next sleep.

Note You need to log in before you can comment on or make changes to this bug.