David Goodenough wrote: > I have some small single board systems on which I run Debian. > They have clocks, but they are not battery backed and so reset > to zero for each run. And by reset to zero you mean the date loaded at boot time from the hardware clock is always "Thu, 01 Jan 1970 00:00:00 +0000", right? > I then set the time using NTP once I have a network connection - > wireless as it happens and therefore not entirely predictable in how > quickly it will connect. Here are some suggestions. I haven't encountered this problem myself but if I were trying to deal with it these are the things I would be doing. YMMV. I would read /usr/share/doc/util-linux/README.Debian.hwclock just to verify understanding. Then I would set the undocumented control variable HWCLOCKACCESS=no in /etc/default/rcS so that the /etc/init.d/hwclockfirst.sh and /etc/init.d/hwclock.sh scripts no longer try to set the system clock from the hardware clock. Since your hardware clock isn't correct the above simply gets the scripts that think that it is out of the way so that they don't conflict with you trying to do other things such as what I am about to suggest next. Then I would create a new script that would set the clock to as reasonable of a value as possible. You don't have a real time value yet but most importantly you don't want to set it to a time that is before the system was stopped. So I would look for a file on the filesystem that is always active on the system. I would extract the time from that file and use it as the basis for the new system time. Then at the very least you would have monotonically increasing time. You would not be duplicating any previous times. Then when NTP sets the system to the actual time it may jump forward. But that is going to happen anyway. And then at least it won't fire cron tasks multiple times. If you do that then I don't think you need to mess with cron at all. Just let it do its own thing. The problems of duplicate cron times will be avoided. I think. For an active file to set the time I would probably look in /var/log/ and select the newest file there. That way even if the system time were zero and updated a particular file such as syslog taking the time backward I would be pretty assured that at least one of the files would have a reasonably current time. The latest of anything there seems most reasonable to me. Something like this: date -d "$(stat --printf "%y\n" $(ls -td /var/log/* | head -n1) )" The use of -d simply displays the date. To actually set the date use the -s option. But the above is safe for testing and development. For a /etc/init.d/ template copy the /etc/init.d/skeleton file and modify it for your purposes. I would create a new script instead of modifying the hwclockfirst.sh so that upgrades don't try to overwrite it with newer versions. You can control your own script and do what you want there. If you have any questions about setting up a new init.d script please ask. I (and others on the list) could create one that did this fairly easily. Or someone else may shoot down my suggestion above. But the above is what I would do if I were faced with your problem. > I would like to make sure that cron (and I am quite happy to > looks at other crons if that makes like easy) does not use an > unset clock as the basis for firing commands. Solve the clock problem at the clock level first and then don't worry about cron as it won't be a problem then. Bob
Attachment:
signature.asc
Description: Digital signature