Example of issue:

* 9 * * * echo 9
* 10 * * * echo 10

The above will fire off an email to the user every minute, but all the "9" responses will happen at 10:00AM -> 10:59AM, while the "10"s will come in at 11:00AM->11:59AM.

Running a job of

* * * * * /bin/date ; /bin/date -u

Returned the expected (correct) date and time. this was true for both UTC and local time (America/Denver). Change this job to run every minute at a specific hour results in the offset (jobs told to run at 9 run at 10, etc etc).

Current debug I have completed:

Okay, thats odd. Maybe my timezone file is somehow messed up? Lets check that

diff -s /etc/localtime /usr/share/zoneinfo/`cat /etc/timezone`
Files /etc/localtime and /usr/share/zoneinfo/America/Denver are identical

I have checked the hardware clock to see if this is off or somehow disagrees with my local settings (run as root).

date ; hwclock
Wed Oct 26 10:50:13 MDT 2016
Wed 26 Oct 2016 10:50:14 AM MDT  -0.204171 seconds

Looks to be off by a second, but that shouldn't make my cron jobs run a full hour off schedule, right?

I am also sure of the following:

  • Has my timezone changed recently? No
  • Did you try manually fixing the timezone anyway? Yes
  • Did you reset cron after fixing the timezone? Yes
  • Have I made sure that the cron service was restarted? Yes
  • Have I restarted the cron service? Yes
  • Are you really sure that cron was restarted? 100% sure Cron has been restarted

Other potentially relevant information:

Running Debian.

cat /etc/debian_version

Current Kernel

uname -a
Linux BigBox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2 (2016-04-08) x86_64 GNU/Linux

Updated Debug:

Ran 'hwclock --systohc', not noticeable changes to behavior. Ran this command to check

Wed Oct 26 12:39:09 MDT 2016
Wed 26 Oct 2016 12:39:11 PM MDT  -0.875328 seconds

I cannot run 'cat /etc/sysconfig/clock' as this file does not exist. Running a find command under the /etc/ tree to find 'clock' confirms that I have no file by that name there.

Checked to see if anything I am aware of has set the CRON_TZ variable. It is not set at the user level, nor at roots level. Have cron echo them out gives no output.

  • 1
    Is the CRON_TZ env var set anywhere?
    – thrig
    Oct 26, 2016 at 17:14
  • try hwclock --systohc just for completeness, and add cat /etc/sysconfig/clock to question ?
    – steve
    Oct 26, 2016 at 17:19
  • Added both suggestions to my information, sadly neither provided much of value. CRON_TZ isn't set under any environment I can see, re-syncing the hwclock gave the same results as before (checked anyway to see if it changed, it did not) and I don't have an '/etc/sysconfig/clock' file.
    – jmurrayufo
    Oct 26, 2016 at 18:46

1 Answer 1


One more place to look: the start-at-boot script(s) for cron, or the old school system crontab file /etc/crontab . It's possible that the TZ environment variable gets set in, say, /etc/init.d/cronie or /lib/systemd/system/crond.service, I'm not sure what Debian uses for init system.

I've seen something like this when I tried to have crond run things every other hour:

0 */2 * * * /opt/dbms/rainstor/archiving/ama_term

crond ran the script on odd-numbered hours. I suspected, but never proved to myself, that it had to do with a daylight savings time confusion.

  • /etc/init.d/cron is grabbing the /etc/timezone file. TZ=cat /etc/timezone. That file appears to be correct (Ran a checksum just to be double sure its identical to what it should be.). /lib/systemd/system/crond.service doesn't seem to want to modify any TZ variables. I'm going to check the */2 suggestion to see if I am seeing the same thing.
    – jmurrayufo
    Oct 26, 2016 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.