6

I have a problem with a user's crontab.

Crontab refuses to run any job unless it's scheduled to run every minute (* * * * *).

An soon as you edit the task to run, say, on minute 15 of every hour, it fails to run.

This runs ok every minute:

* * * * * touch /tmp/test01

This fails to run on minute 15 of every hour. It just won't run.

15 * * * * touch /tmp/test02
  • What's causing this?
  • How can it be solved?

OS is RedHat 4.

I always edit the cron with crontab -e and EDITOR is set to vi. I've changed back and forth between 15 * * * * (minute can change) and * * * * * and the result is the same. It only likes five asterisks.

HUGE EDIT:

I followed @shane-h 's question and tested for */2 * * * * (every other minute) and it worked! Then I discovered something revealing:

I had made a test with this string 37 * * * * touch /tmp/prueba_777777

To my surprise the thing actually ran but look at the date of the file:

-rw-r--r-- 1 orashut dba 0 Aug 8 08:07 prueba_777777

Recently the server was set to the new Venezuela TimeZone, which is now -04:00, but used to be -04:30.

Whem you run the date command it shows the correct date. When you create a file, the file date in the FS is correct. But somehow cron jobs are running 30 minutes earlier. That's why when I scheduled a job for some minutes in the future it didn't work, because to the cron daemon that time had already passed. If I waited almost an hour it would have run at exactly minutes-30. That's why the touched file is 30 minutes earlier that the schedule's 37.

So the question now is:

It's evident that the cron daemon is working with the old timezone while the rest of the server is working with the new timezone.

How can I fix the cron daemon's understanding of the new timezone?

Improve this question
10
  • 3
    How was the crontab file edited? If via vi or similar then cron won't necessarily have picked up the change. Use crontab -e (or if as root, crontab -u username -e) to edit the file. – Stephen Harris Jul 29 '16 at 12:49
  • 1
    have you check /var/log/messages ? – Archemar Jul 29 '16 at 13:01
  • 1
    @Rahul No. No error at all. No message in mail. It only likes five asterisks. And the task I'm testing is a simple touch. As long as you give it the five asterisks it likes, the cron happily runs the touch every minute. But if you schedule to a minute in the future and wait until that minute nothing happens, no error, no mail, nada. It's five asterisks or nothing. – Tulains Córdova Jul 29 '16 at 13:03
  • 1
    There is some kind of time adjust based on a ntp server? If there is, try to disable everything related to it temporary, and see if cron work now. – Luciano Andress Martini Jul 29 '16 at 13:10
  • 1
    Do you see anything interesting in /var/log/cron? – Zachary Brady Jul 29 '16 at 13:51
1

I can't give you a specific answer, but here is how i would go about troubleshooting this:

  1. Try more combinations to find another working expression. How about: */2 * * * * (every other minute), or * */2 * * * (every minute, every other hour). It would be interesting to establish that any relative expression works while fixed expressions do not.

  2. When you save, do you see the confirmation message "New crontab installed?" (or something similar)

  3. Can you do a crontab -l to see your message?

  4. Is this a user crontab or system crontab?

  5. Do you see messages in syslog? If you add a second, * * * * * cron you should see that every minute, and if you add the every-other-minute variant, can you see in syslog just the more frequent job?

  6. Can you configure a working at command?

  7. When you have this figured out, I would suggest using a service I built, https://cronitor.io to keep an eye on your important jobs. It's free for a developer to monitor one job and there are paid plans for business use. I had become too much of an expert cron debugger over the years and knew that if I needed a solution to monitor my important jobs other people probably did too.

from comments:

Cron uses the same system timezone for kicking-off jobs, so I would try just resetting that:

  1. Set your timezone again, just to be thorough: on Red Hat use redhat-config-date

  2. Restart the cron daemon. I think on your OS version: /etc/init.d/crond restart

Improve this answer
3
  • I tried the every two minutes option and it worked! In the other hand I just discovered something, I'll update the answer. Stay tuned. – Tulains Córdova Aug 8 '16 at 12:25
  • I made an EDIT no the question. Problem seems to be timezone-related. Please read and let me know your suggestion. – Tulains Córdova Aug 8 '16 at 12:38
  • 1
    @TulainsCórdova Cron uses the same system timezone for kicking-off jobs, so I would try just resetting that: 1. Set your timezone again, just to be thorough: on redhat use redhat-config-date 2. Restart the cron daemon. I think on your os version: /etc/init.d/crond restart – Shane H Aug 8 '16 at 16:42
2

So the question now is:

It's evident that the cron daemon is working with the old timezone while the rest of the server is working with the new timezone.

How can I fix the cron daemon's understanding of the new timezone?

My guess is the a timezone data update package has been installed (tzdata RPM or similar) but the server has not been rebooted and the crond daemon has not been restarted after the update, so crond is still using the old timezone data it loaded when it was originally started.

If that is the problem, then restarting the daemon should fix the problem, as Shane H commented: service crond restart or /etc/init.d/crond restart should do it. You should also consider restarting any other long-running system daemons that may record timestamps, like sendmail.

Improve this answer

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.