# cron is one hour behind



## Pushrod (Jan 31, 2011)

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.


----------



## DutchDaemon (Jan 31, 2011)

Never heard of this. Maybe run [cmd=]service cron restart[/cmd] to see if that fixes things?

Also check whether you're overruling 
	
	



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


----------



## wblock@ (Jan 31, 2011)

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.


----------



## Pushrod (Feb 1, 2011)

cron was running with -s, which until now, I hadn't even heard of. This was found in /etc/defaults/rc.conf.


----------



## wblock@ (Feb 1, 2011)

For 8.2, /etc/defaults/rc.conf has

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


----------



## Pushrod (Feb 1, 2011)

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.


----------



## anomie (Feb 1, 2011)

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


----------



## DutchDaemon (Feb 1, 2011)

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 
	
	



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


----------



## Pushrod (Feb 4, 2011)

I don't know why this was a problem, I just know that cron_dst="NO" is all it took to fix it.


----------



## DutchDaemon (Feb 4, 2011)

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


----------

