Hi Jon,
> All,
>
> I think I've found a bug in crond. The man page (SL 5.2) says:
>
> Daylight Saving Time and other time changes
>
> Local time changes of less than three hours, such as those
> caused by the start or end of Daylight Saving Time, are
> handled specially. This only applies to jobs that run at a specific
> time and jobs that are run with a granularity greater than one
> hour. Jobs that run more frequently are scheduled normally.
>
> If time has moved forward, those jobs that would have run in the
> interval that has been skipped will be run immediately.
> Conversely, if time has moved backward, care is taken to avoid
> running jobs twice.
>
> *** Time changes of more than 3 hours are considered to be corrections
> *** to the clock or timezone, and the new time is used immediately.
>
> However, today I found that when changing the system time from local
> time (MST) to UTC on a computer running SL 5.2, crond continued to
> use local time. It required a "/etc/rc.d/init.d/crond restart" to
> make it use UTC, the new system time. FYI, I changed the system
> time by
This isn't a bug. When software starts up (pick a package, any package) it
reads the timezone information from the server _only_ on startup. The daemon
is then running and never (needs) to re-read the timezone information unless
it's restarted.
If this is a bug with crond, then it's also a bug with every other piece of
software that's out there and runs as a daemon (oracle, mysql, apache, xinetd,
etc).
Software developers just do not write software that re-reads time zone
information periodically, and nor should they.
In production environments, when you change time zone information it's
recommended you reboot your servers, even when it's not feasible to do so. The
reason? you may not know every single daemon/service/app that's running on the
server which you cannot restart.
Regards,
Michael.
> "rm /etc/localtime ; ln -s /usr/share/zoneinfo/UTC /etc/localtime".
>
> Jon
------- End of Original Message -------
|
