cron on a system without a hardware persistant clock
 

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

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.

I could use update-rc.d to disable cron, and only enable it
once wpa_supplicant has established the connection, but then
what if the wireless link goes down and back up while the
hardware is powered up, in which case it would get restarted
unnecessarily.

Does anyone know if there is a way to tell and of the crons to
ignore unset times?

David


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109271011.33513.david.goodenough@btconnect.com" >http://lists.debian.org/201109271011.33513.david.goodenough@btconnect.com

cron on a system without a hardware persistant clock
 

David Goodenough <david.goodenough@btconnect.com> wrote:
> I could use update-rc.d to disable cron, and only enable it
> once wpa_supplicant has established the connection, but then
> what if the wireless link goes down and back up while the
> hardware is powered up, in which case it would get restarted
> unnecessarily.

I think you're almost there. What about disabling the start scripts for
cron in the /etc/rc*.d directories, and having your network-up trigger
"invoke-rc.d cron start". Don't have your network-down trigger the
corresponding cron stop, though.

On my debian system there isn't a "real" problem trying to start cron
multiple times (start-stop-daemon manages the process via its pid file):

$ ps -ef | grep [c]ron
root 3084 1 0 09:14 ? 00:00:00 /usr/sbin/cron
$ sudo invoke-rc.d cron start
Starting periodic command scheduler: cron failed!
$ sudo invoke-rc.d cron start
Starting periodic command scheduler: cron failed!
$ ps -ef | grep [c]ron
root 3084 1 0 09:14 ? 00:00:00 /usr/sbin/cron

If you're really keen, put a hook into the /etc/init.d/cron script that
exits unless the date/time is plausible. You can then call it at start,
at network-up, and maybe on other events. The same thing could work from
atd, too, if you have it in your environment.

Chris


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 72m8l8xhhg.ln2@news.roaima.co.uk">http://lists.debian.org/72m8l8xhhg.ln2@news.roaima.co.uk

cron on a system without a hardware persistant clock
 

Le 15244ième jour après Epoch,
David Goodenough écrivait:

[...]
> I could use update-rc.d to disable cron, and only enable it
> once wpa_supplicant has established the connection, but then
> what if the wireless link goes down and back up while the
> hardware is powered up, in which case it would get restarted
> unnecessarily.
>
> Does anyone know if there is a way to tell and of the crons to
> ignore unset times?

You can take a look to anacron, which is designed for machines with
suspend/resume cycles.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87mxdqp7cw.fsf@fermat.tourde.home">http://lists.debian.org/87mxdqp7cw.fsf@fermat.tourde.home

cron on a system without a hardware persistant clock
 

On Tue, 27 Sep 2011 10:11:33 +0100, 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.

You mean that system always starts with no date set? :-o

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

Mmm... I would be careful with this, NTP may refuse to sync if the offset
between current/real date and system date is too wide.

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

There are also "/etc/cron.hourly|daily|weekly" folders where you can put
your scripts which will be run by cron at no "specific" time, not sure if
this can be useful to your purpose or you seek instead for a system wide
solution to your timing issues.

> I could use update-rc.d to disable cron, and only enable it once
> wpa_supplicant has established the connection, but then what if the
> wireless link goes down and back up while the hardware is powered up, in
> which case it would get restarted unnecessarily.
>
> Does anyone know if there is a way to tell and of the crons to ignore
> unset times?

Having a system configured with bad time may experience stability issues
as most of the base scripts rely on the right time to run their jobs by
means of cron and/or other scheduler daemons.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.27.14.00.37@gmail.com">http://lists.debian.org/pan.2011.09.27.14.00.37@gmail.com

cron on a system without a hardware persistant clock
 

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
" $(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

cron on a system without a hardware persistant clock
 

Camaleón wrote:
> David Goodenough wrote:
> > 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.
>
> Mmm... I would be careful with this, NTP may refuse to sync if the offset
> between current/real date and system date is too wide.

That used to be true with older versions of Debian when there was a
separate 'ntpdate' package. 'ntpdate' would be run to step the clock
before starting the 'ntp' daemon. If you only ran 'ntp' then if the
time were too far off (1000s) then ntpd would simply refuse as a
sanity check and exit. So you used to need to use ntpdate or other
first before ntp.

But recent versions of Debian combined those two packages. Now there
is only the one single combined 'ntp' package and it will step the
clock as needed when it starts up. This behavior is accomplished
through the 'ntpd -g' option set in the /etc/default/ntp file.

Bob

cron on a system without a hardware persistant clock
 

On Tuesday 27 Sep 2011, Camaleón wrote:
> On Tue, 27 Sep 2011 10:11:33 +0100, 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.
>
> You mean that system always starts with no date set? :-o
Absolutely yes, that is my problem. No battery backup for the time
when the box is powered down, so on boot the time is always the 1st
Jan 1970 00:00am.
>
> > 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.
>
> Mmm... I would be careful with this, NTP may refuse to sync if the offset
> between current/real date and system date is too wide.
by NTP I mean using the NTP protocols, I use ntpdate which does not suffer
from this 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.
>
> There are also "/etc/cron.hourly|daily|weekly" folders where you can put
> your scripts which will be run by cron at no "specific" time, not sure if
> this can be useful to your purpose or you seek instead for a system wide
> solution to your timing issues.
>
> > I could use update-rc.d to disable cron, and only enable it once
> > wpa_supplicant has established the connection, but then what if the
> > wireless link goes down and back up while the hardware is powered up, in
> > which case it would get restarted unnecessarily.
> >
> > Does anyone know if there is a way to tell and of the crons to ignore
> > unset times?
>
> Having a system configured with bad time may experience stability issues
> as most of the base scripts rely on the right time to run their jobs by
> means of cron and/or other scheduler daemons.
which is why I want to disable the cron type activities until I have
set the time/date to a real one.

David
>
> Greetings,


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109281008.27811.david.goodenough@btconnect.com" >http://lists.debian.org/201109281008.27811.david.goodenough@btconnect.com

cron on a system without a hardware persistant clock
 

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
" $(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-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201109281013.04729.david.goodenough@btconnect.com" >http://lists.debian.org/201109281013.04729.david.goodenough@btconnect.com

cron on a system without a hardware persistant clock
 

On Wed, 28 Sep 2011 10:08:27 +0100, David Goodenough wrote:

> On Tuesday 27 Sep 2011, Camaleón wrote:
>> On Tue, 27 Sep 2011 10:11:33 +0100, 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.
>>
>> You mean that system always starts with no date set? :-o
> Absolutely yes, that is my problem. No battery backup for the time when
> the box is powered down, so on boot the time is always the 1st Jan 1970
> 00:00am.

(...)

Can you point us to that piece of hardware?

Maybe you can consier in adding an RTC (if not present in motherboard) or
an external battery to get a clock at booting, if not atomically synced,
at least with "decent" values.

>> Having a system configured with bad time may experience stability
>> issues as most of the base scripts rely on the right time to run their
>> jobs by means of cron and/or other scheduler daemons.
> which is why I want to disable the cron type activities until I have set
> the time/date to a real one.

I don't think that's the right way to deal with this.

In order of importance:

1. Setting up the clock
2. Run cron
3. Run the scripts that depend on cron (system oriented)
4. The rest of the scheduled tasks/jobs (user oriented)

So I would try to add a reliable source (dial-up or GSM modem...) from
where to sync the time or at least to use it as a backup source from
where to gather the data if wifi fails or is off for whataever reason.

Greetings,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: pan.2011.09.28.12.00.02@gmail.com">http://lists.debian.org/pan.2011.09.28.12.00.02@gmail.com

cron on a system without a hardware persistant clock
 

David Goodenough wrote:
> Bob Proulx wrote:
> > 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?

Because it ensures that the system time is always monotonically
increasing. Time points are never repeated. Monotonically increasing
time is an essential point of time keeping. Otherwise you could have
system logs duplicated. Otherwise you could have cron trigger
cronjobs multiple times for the same task.

But I am surprised by your question. If you believe that the Unix
zero epoch is always as good of a time as any then what is your
concern? It can't be cron since those two concerns are one concern
inextricably intertwined. Being concerned about cron *is* being
concerned that the system has a proper monotonically increasing clock
time.

> What does cron do with events that should have happened during the
> jump that ntpdate will cause in the clock.

Nothing. Since those time points did not happen then cron did not
trigger them.

The anacron package mentioned by others is designed specifically to
handle the cron.daiy et al scripts. That way if your machine is off
at the time they would run but boots shortly afterward those tasks
will still be run. Think of a laptop being suspended and resumed
skipping over those times of day. With anacron installed those daily
scripts will run later when the machine has been resumed. I am not
really a fan of anacron myself but it does provide a useful function
for those cases.

> If they are ignored then I suppose I am safe provided I do not set
> things too close to 00:00am.

Mostly, yes. Don't have any cronjobs within a reasonable window of
time and you will be fine. For example I avoid scheduling jobs
between 2am-3am because in my timezone that is when DST changes happen
and that will cause tasks to either be skipped or run twice.

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

You can look this up for yourself:

$ cat /etc/crontab
# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
25 6 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Since 6am is outside most countries DST changes the problem of DST is
avoided.

Bob