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.
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.