10

I have CentOS and when I run date command in shell it return me something like:

Thu Apr 28 14:08:20 GMT 2011

however cron jobs are running at PST time.Means if I specify

15 7 * * * command

it will run at 7 PST not 7 GMT . Please tell me why this is happening.

Thanks

Outputs of hwclock command:

/usr/sbin/hwclock --utc Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.

And when I ran using debug:
/usr/sbin/hwclock --debug hwclock from util-linux-2.13-pre7 hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. No usable clock interface found. Cannot access the Hardware Clock via any known method

chutz
  • 7,569
  • 1
  • 28
  • 57
shashuec
  • 277
  • 2
  • 3
  • 6

4 Answers4

9

More than likely not your problem, but worth a mention -- If your /etc/localtime changes after crond has loaded, it will continue to be stuck in the previous timezone. Simply restart/reload crond, and it will pick up this change.

Another 'gotcha' is that cron will adhere to the TZ environment variable. This can be set in-line in a crontab, affecting any lines that follow it, but it seems more likely that TZ is getting set in the environment that loads crond.

I just tried a couple variations (tweaking the hr/min fields) on the following to determine if/when these two jobs would be run. The output that gets stuffed into /tmp/tzout.localtime should also give you some hints about if $TZ is somehow getting set in the environment that's loading crond or not.

* * * * *     echo $TZ `date` >> /tmp/tzout.localtime
TZ=GMT
* * * * *     echo $TZ `date` >> /tmp/tzout.gmt

While I don't claim to know exactly where your problem lies, hopefully this sheds a little light on the solution!

walkeran
  • 356
  • 1
  • 5
  • Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running the `set` command as a cron test. It might show something interesting being set in another variable. – chutz Oct 29 '12 at 12:29
  • It was definitely my problem, thanks! – Amir Almusawi Dec 02 '20 at 16:53
6

The question is a bit old but changing the time zone and getting crond to recognize the change is still a problem on CentOS: I have found that after changing the time zone the syslog deamon also has to be restarted using

/etc/init.d/rsyslog

See Timzone incorrect for log files only?

Community
  • 1
MarcFasel
  • 161
  • 1
  • 4
1

There are two ways to change the timezone (on CentOS 5, 6, 7 at least, as well as the corresponding RHEL 5, 6 & 7 distros, Amazon Linux and Amazon Linux 2, which are based on CentOS 6 & 7 respectively), depending on the scope of what you're trying to affect.

First, you need to run tzselect (choose your continent, country and time zone) to get the correct value for your TZ environment variable, then:

1. Follow the instructions it outputs, to change the time zone for programs you run from the command line, all your interactive shell processes (here is mine, for example, showing the TZ value for U.S. Eastern Time):

You can make this change permanent for yourself by appending the line
        TZ='America/New_York'; export TZ
to the file '.profile' in your home directory; then log out and log in again.

Here is that TZ value again, this time on standard output so that you
can use the /usr/bin/tzselect command in shell scripts:
America/New_York

2. But to change the "system" timezone, used by syslog, crond, mysql, apache and any other daemon processes spawned by the init system at boot time, you must become root, and change these two files:

/etc/sysconfig/clock
/etc/localtime

When using a server hosted in Texas or California, for instance, I've found these pointing to Central or Pacific time, which is inconvenient for me, and all our users, developers and sysadmins are on the East Coast too so, to change the system time, I do these steps:

# step 1
sudo vim /etc/sysconfig/clock

# change ZONE from UTC (or whatever it is) to your local TZ value:
ZONE="America/New York"

# (but leave this 2nd line alone!)
UTC=True


# step 2: copy your TZ value's dir/file (under zoneinfo) onto /etc/localtime
sudo cp -v /usr/share/zoneinfo/America/New_York /etc/localtime

# step 3
reboot

# Or if all you care about is crond, for instance, just
sudo systemctl restart crond.service # for CentOS 7 / Amazon Linux 2

# Or mysql on older init.d style RHEL 6 / CentOS 6 / Amazon Linux systems:
sudo /etc/init.d/mysqld restart
gigawatt
  • 179
  • 1
  • 6
0

I believe that "cron" runs based on the hardware clock, not the configured time-zone's clock. Try looking at "hwclock" rather than "date" as "date" is modified to your users' configured time-zone.

TheCompWiz
  • 7,349
  • 16
  • 23
  • I got few errors while running hwclock: /usr/sbin/hwclock --utc Cannot access the Hardware Clock via any known method. Use the --debug option to see the details of our search for an access method. and when I ran using debug: /usr/sbin/hwclock --debug hwclock from util-linux-2.13-pre7 hwclock: Open of /dev/rtc failed, errno=2: No such file or directory. No usable clock interface found. Cannot access the Hardware Clock via any known method – shashuec Apr 28 '11 at 14:31
  • it's very strange that you would be seeing errors with hwclock... but any chance you can look @ bios-level for the time? is it set to the correct time for PST? – TheCompWiz Apr 29 '11 at 13:01
  • 1
    -1, because all CentOS cron implementations that I am aware of (vixie-cron on CentOS 5, and cronie on CentOS 6) run based on the system clock, so this statement is just not true. – chutz Oct 29 '12 at 12:27