cron is one hour behind

Pushrod

Pushrod

Yes, you read correctly. cron is an hour behind.

I have something that should run in about 1 minute at 17:15. It runs at 18:15, and is logged as having run at 17:15 in syslog, despite the real time being 18:15.

The system uptime is 274 days, so cron would have made a jump over DST correction back in November. I have not changed TZ since I got this server (days after it last booted on May 1, 2010).

Is this a bug or is there another problem? The clock is not wrong. Syslog dates are only wrong in /var/log/cron, messages is right, as are others.
 
Never heard of this. Maybe run [cmd=]service cron restart[/cmd] to see if that fixes things?

Also check whether you're overruling
Code: 
cron_dst="YES"		# Handle DST transitions intelligently (YES/NO)
which is normally present in /etc/defaults/rc.conf and/or look at the -s and -o flags in cron(8).

Never used/needed them, but who knows.
 
Are all cron times off, or just that one job? Do you have non-default cron flags set in /etc/rc.conf? Some commands have their own additional delays built in, like portsnap(8)'s cron option.
 
cron was running with -s, which until now, I hadn't even heard of. This was found in /etc/defaults/rc.conf.
 
For 8.2, /etc/defaults/rc.conf has
Code: 
cron_enable="YES"       # Run the periodic job daemon.
cron_program="/usr/sbin/cron"   # Which cron executable to run (if enabled).
cron_dst="YES"          # Handle DST transitions intelligently (YES/NO)
cron_flags=""           # Which options to pass to the cron daemon.

That file does say "You should not edit this file!" at the top, although it should probably be the first line.
 
cron_dst="YES" implies -s. I had to override it with cron_dst="NO" in /etc/rc.conf.

No edits to the default rc.conf were made.
 
If all else fails, I'd run tzsetup(8), select your timezone (again), and then restart crond afterward. (Should be a harmless sequence of events, in any case.)
 
I run cron -s (as seen in ps ax) on all of my machines, and none have (had) problems with DST changes, All cron instances run on the default settings of
Code: 
cron_enable="YES"       # Run the periodic job daemon.
cron_program="/usr/sbin/cron"   # Which cron executable to run (if enabled).
cron_dst="YES"          # Handle DST transitions intelligently (YES/NO)
cron_flags=""           # Which options to pass to the cron daemon.
 
I don't know why this was a problem, I just know that cron_dst="NO" is all it took to fix it.
 
Interesting .. so far as I know, this only affects jobs that are running around the time of DST changes, i.e. twice a year around 2/3 AM .. Oh well ;)
 
You must log in or register to reply here.
Back
Top