On Wednesday 28 Sep 2011, Bob Proulx wrote: > 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? Yes > > > 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. well the 1st Jan 1970 00:00am is as good a a value as any, how would setting it to some other value help?
What does cron do with events that should have happened during the jump that ntpdate will cause in the clock. If they are ignored then I suppose I am safe provided I do not set things too close to 00:00am. But then when does it do daily and monthly tasks, 00:00am would seem like a reasonable time, or does it do it later to avoid problems with daylight saving changes. David > > 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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201109281013.04729.david.goodeno...@btconnect.com
