On Tue, Oct 30, 2001 at 04:33:46PM +1100, John Clarke wrote:
> Oct 29 03:05:10 wombat ntpdate[28814]: adjust time server 192.189.54.33 offset
>0.184338 sec
> Oct 29 04:01:00 wombat CROND[28974]: (root) CMD (run-parts /etc/cron.hourly)
> Oct 29 04:01:59 wombat CROND[29027]: (root) CMD (run-parts /etc/cron.daily)
> Oct 29 04:02:00 wombat CROND[29089]: (root) CMD (run-parts /etc/cron.daily)
> Oct 29 04:05:11 wombat ntpdate[29572]: adjust time server 192.189.54.33 offset
>0.182355 sec
> Oct 29 05:00:59 wombat CROND[29775]: (root) CMD (run-parts /etc/cron.hourly)
> Oct 29 05:01:01 wombat CROND[29808]: (root) CMD (run-parts /etc/cron.hourly)
> Oct 29 05:05:12 wombat ntpdate[29848]: adjust time server 192.189.54.33 offset
>0.180785 sec
>
> Any ideas?
I don't think crond likes having the system time changed like that.
It ran cron.daily and cron.hourly 1 second early, which to me means
crond was keeping its own time independently of the system time, then
it may have synced its time with the system, noticed that it lost 1
second and reran the scripts.
(I'm only guessing here, feel free to read the source :)
Do the other machines run ntpdate?
Do the other machines lose 0.2 seconds an hour?
Is there any reason why you're not running ntpd?
I think ntpd will eventually stabilise the clock so it won't
drift so much. (you can do it by hand as well I think,
/etc/adjtime)
You could artificially add 2 seconds to the clock and see what happens.
(my guess, cron would run the scripts 2 seconds early, then rerun the
scripts again)
Or, you could reload crond after ntpdate runs.
Keep in mind that I'm making all this up as I go.
--
chesty
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug
