Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've tried eliminating many of the common errors,

1) ensuring that the PATHs are available for cron

2) there is an endline at the end of crontab file

3) the timezone is set-up by:

cd /etc
cp /usr/share/zoneinfo/Asia/Singapore /etc/localtime

running date in bash, I get:

Tue Sep 17 15:14:30 SGT 2013

in order to check if cron is using the same time,

* * * * * date >> date.txt

is giving the same date output in date.txt.


This is the script I'm trying to execute:

[event.sh]

#!/usr/bin/env bash
echo data > /root/data.txt

using crontab -e, the line below works,

* * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

15 * * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

however, when i tried some other arguments, hoping it would run at 2.50pm:

50 14 * * * /bin/bash /root/event.sh >/tmp/debug.log 2>&1

or

50 14 * * * (cd /root ; ./event.sh >/tmp/debug.log 2>&1)

it will no longer work. Seems like there is a problem with my hour argument. Nothing could be found in the /tmp/debug.log file either.

SOLUTION:

it turned out i have to restart the cron service after making changes to TZ.

share|improve this question
1  
any error in logs ? can you please try with absolute path instead of ~/event.sh try with /home/username/event.sh –  Rahul Patil Sep 17 '13 at 7:02
1  
also do small modification like * * * * * /bin/bash /root/event.sh >/tmp/debuge.log 2>&1 –  Rahul Patil Sep 17 '13 at 7:15
1  
You say that the time zone is set correctly, but are you absolutely sure of that? Try adding an entry like * * * * * date and confirm that date shows the expected time. Note that setting the TZ environment variable from within the crontab might not affect the time zone as used by the cron daemon itself, but it will affect processes launched through cron, so if you set TZ in your crontab I'd suggest commenting it out temporarily and setting the time using the system clock's timezone (probably UTC if you are single-booting Linux, but may be local time) instead. –  Michael Kjörling Sep 17 '13 at 7:23
1  
You are missing the point, @adsisco. I'm asking that you remove any TZ directive that might be in the crontab and then try it again. That will make date execute with the same TZ as the cron daemon itself does, letting us see what time zone cron wants the time fields in. /etc/localtime only affects display, not the system clock, and I doubt it affects cron. By doing this test, we can be sure that your problem is in no way related to time zones (which frankly it seems like to me). –  Michael Kjörling Sep 17 '13 at 8:14
1  
actually, i think i just fixed it by rebooting the system... could it be that i have to restart cron service after making changes to TZ? @MichaelKjörling. THANKS! for pointing me to possible timezone problems. –  adsisco Sep 17 '13 at 8:32

1 Answer 1

up vote 1 down vote accepted

First off, the odds that you are hitting a bug that causes one field to be incorrectly considered seems exceptionally low. It's more likely to be a misunderstanding of what's going on and what cron expects.

In this case, we found out in the comments to the question that it was very likely a timezone related issue. For this, you would:

  • Add an entry like * * * * * date to the crontab
  • Remove (or comment out) any TZ assignment from the crontab

This forces date to run with the time zone setting of the invoker, which means the cron daemon. Look at the output; it will show what time zone cron is using internally, and thus highly likely which time zone it wants its time fields in. If you have a TZ assignment in the crontab, it is easily possible that the TZ environment variable assignment is passed through to the invoked commands but cron itself uses some other time zone. By commenting out or removing the TZ assignment, you avoid this ambiguity.

Also note that any changes to the system global timezone settings (including e.g. /etc/localtime) almost certainly require at least a restart of the cron daemon, and possibly (though unlikely) a system reboot to take full effect. Editing the TZ assignment in the crontab should not require a reload of the cron daemon, as it should detect that the file has been changed and reload it automatically.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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