9

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
8.6

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 

date;hwclock
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.

Improve this question
3
  • 1
    Is the CRON_TZ env var set anywhere?
    – thrig
    Commented Oct 26, 2016 at 17:14
  • try hwclock --systohc just for completeness, and add cat /etc/sysconfig/clock to question ?
    – steve
    Commented 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
    Commented Oct 26, 2016 at 18:46

1 Answer 1

Reset to default
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.

Improve this answer
1
  • /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
    Commented Oct 26, 2016 at 18:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .