question regarding cron and DST

[Chris Fadrowski]

Since DST took effect, cron is off by one hour. The system date is correct.

This shows that /var/adm/cron/log was updated at 11:20 this morning, but the date in the log file is one hour earlier.

root@host:/var/adm/cron>date
Mon Mar 12 11:25:44 CDT 2007
root@host:/var/adm/cron>ll log
-rw-r--r-- 1 root root 3176197 Mar 12 11:20 log
root@host:/var/adm/cron>tail log
< oracle 27521 c Mon Mar 12 10:00:00 CST 2007
> CMD: /home/oracle/scripts/legato/check_legato_status.sh > /home/oracle/scripts/legato/_check_legato_status.log 2>&1
> root 28902 c Mon Mar 12 10:05:00 CST 2007
< root 28902 c Mon Mar 12 10:05:01 CST 2007
> CMD: /home/oracle/scripts/misc/space_used.sh > /home/oracle/scripts/misc/_space_used.lst 2>&1
> oracle 1756 c Mon Mar 12 10:15:00 CST 2007
< oracle 1756 c Mon Mar 12 10:15:00 CST 2007
> CMD: /home/oracle/scripts/misc/space_used.sh > /home/oracle/scripts/misc/_space_used.lst 2>&1
> oracle 3230 c Mon Mar 12 10:20:00 CST 2007
< oracle 3230 c Mon Mar 12 10:20:00 CST 2007

This shows that cron didn't make the adjustment for DST at 2am, even though the o/s itself did.

> CMD: /home/oracle/scripts/legato/check_legato_status.sh > /home/oracle/scripts/legato/_check_legato_status.log 2>&1
> root 23148 c Sun Mar 11 01:55:00 CST 2007
< root 23148 c Sun Mar 11 01:55:00 CST 2007
> CMD: /home/oracle/scripts/misc/space_used.sh > /home/oracle/scripts/misc/_space_used.lst 2>&1
> oracle 23379 c Sun Mar 11 02:00:00 CST 2007
< oracle 23379 c Sun Mar 11 02:00:00 CST 2007
> CMD: /home/oracle/scripts/legato/check_legato_status.sh > /home/oracle/scripts/legato/_check_legato_status.log 2>&1
> root 23551 c Sun Mar 11 02:05:00 CST 2007
< root 23551 c Sun Mar 11 02:05:01 CST 2007
> CMD: /home/oracle/scripts/legato/check_legato_status.sh > /home/oracle/scripts/legato/_check_legato_status.log 2>&1
> root 23950 c Sun Mar 11 02:15:17 CST 2007
> CMD: /home/oracle/scripts/misc/space_used.sh > /home/oracle/scripts/misc/_space_used.lst 2>&1
> oracle 23951 c Sun Mar 11 02:15:17 CST 2007
< oracle 23951 c Sun Mar 11 02:15:17 CST 2007
< root 23950 c Sun Mar 11 02:15:17 CST 2007

[A. Clay Stephenson · Accepted solution]

You need to stop and restart the cron daemon. It's really a good idea to reboot the box unless you are familiar with all the long-running processes on your box. A given tztab entry is cached by the application so that once read, tztab is not consulted again. Originally, tztab was read each time a ctime function was called so that your problem would be handled but there was an obvious performance penalty for something that changes so seldom so that later patches cached the tztab entry. It was a tradeoff of performance vs. latency --- and a reasonable choice.

[Pete Randall]

Chris,

There are special installation instructions with the patch:

"While it is not strictly required to reboot
the system after modifying the rules in the /usr/lib/tztab file, running processes using
a timezone with a changed rule need to be
restarted to apply the new rules. Processes
like cron(1M), which depend on proper
interpretation of timestamps in the future,
should be restarted as soon as possible.
Processes that only timestamp messages should be restarted before the changes take effect."

Most people just reboot so that everything is covered but you can just stop and restart cron or any other processes.


Pete

[Chris Fadrowski]

is there a safe way to stop and start cron without killing the pid?

[James R. Ferguson]

Hi CHris:

# /sbin/init.d/cron stop
# /sbin/init.d/cron start

Regards!

...JRF...

[Christian Tremblay]

/sbin/init.d/cron stop;/sbin/init.d/cron start

That will stop/restart the cron daemon ( with a different PID) but why do you want to preserve the current PID ?

Chris

[Chris Fadrowski]

no concern with the PID, just can't reboot until an outage night which i plan to do but in the mean time i want to stop and start cron.

thanks Gentlemen,