cron running at different timezone and date command shows different time zoneTimzone incorrect for log files only?server restart after timezone changeCron job not running on specified timeRunning a cron job manually and immediatelyCentOS Cron running at wrong time, 5hrs late (Logwatch)Passing date/time to cron job commandCron job with $(date) command and redirect won't runWhere does Cron checks the time zone on Debian?CPU frequency shows different numbers from time to timeCron not running at specified timecron not running specific commandCronD ignoring command and running hourly
Plot twist where the antagonist wins
Does this degree 12 genus 1 curve have only one point over infinitely many finite fields?
Boss wants me to falsify a report. How should I document this unethical demand?
General purpose replacement for enum with FlagsAttribute
Would Brexit have gone ahead by now if Gina Miller had not forced the Government to involve Parliament?
Why do airplanes use an axial flow jet engine instead of a more compact centrifugal jet engine?
Where is the logic in castrating fighters?
Is floating in space similar to falling under gravity?
Would the Geas spell work in a dead magic zone once you enter it?
Why colon to denote that a value belongs to a type?
Rename photos to match video titles
ESTA/WVP - leaving US within 90 days, then staying in DR
How strong are Wi-Fi signals?
Is this resistor leaking? If so, is it a concern?
Different circular sectors as new logo of the International System
What is the object moving across the ceiling in this stock footage?
How to respond to an upset student?
Employer demanding to see degree after poor code review
Approximate solution : factorial and exponentials
What does the view outside my ship traveling at light speed look like?
Full horizontal justification in table
Seed ship, unsexed person, cover has golden person attached to ship by umbilical cord
Command to Search for Filenames Exceeding 143 Characters?
How many chess players are over 2500 Elo?
cron running at different timezone and date command shows different time zone
Timzone incorrect for log files only?server restart after timezone changeCron job not running on specified timeRunning a cron job manually and immediatelyCentOS Cron running at wrong time, 5hrs late (Logwatch)Passing date/time to cron job commandCron job with $(date) command and redirect won't runWhere does Cron checks the time zone on Debian?CPU frequency shows different numbers from time to timeCron not running at specified timecron not running specific commandCronD ignoring command and running hourly
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
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
centos cron
add a comment |
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
centos cron
add a comment |
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
centos cron
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
centos cron
centos cron
edited Oct 29 '12 at 12:27
chutz
6,2831948
6,2831948
asked Apr 28 '11 at 14:11
shashuecshashuec
167225
167225
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
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!
Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running thesetcommand as a cron test. It might show something interesting being set in another variable.
– chutz
Oct 29 '12 at 12:29
add a comment |
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?
add a comment |
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.
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
add a comment |
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
add a comment |
protected by Michael Hampton♦ Apr 18 '18 at 21:28
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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!
Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running thesetcommand as a cron test. It might show something interesting being set in another variable.
– chutz
Oct 29 '12 at 12:29
add a comment |
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!
Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running thesetcommand as a cron test. It might show something interesting being set in another variable.
– chutz
Oct 29 '12 at 12:29
add a comment |
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!
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!
answered Apr 28 '11 at 16:22
walkeranwalkeran
1865
1865
Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running thesetcommand as a cron test. It might show something interesting being set in another variable.
– chutz
Oct 29 '12 at 12:29
add a comment |
Good idea to also check if there is a TZ variable set for the user, as opposed to cron. I would also recommend running thesetcommand as a cron test. It might show something interesting being set in another variable.
– chutz
Oct 29 '12 at 12:29
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
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
add a comment |
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?
add a comment |
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?
add a comment |
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?
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?
edited Apr 13 '17 at 12:14
Community♦
1
1
answered Nov 7 '14 at 3:09
MarcFaselMarcFasel
1414
1414
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
answered Apr 28 '11 at 14:18
TheCompWizTheCompWiz
6,9131122
6,9131122
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
add a comment |
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
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
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
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
-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
-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
add a comment |
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
add a comment |
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
add a comment |
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
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
edited May 14 at 13:26
answered May 14 at 13:20
gigawattgigawatt
13915
13915
add a comment |
add a comment |
protected by Michael Hampton♦ Apr 18 '18 at 21:28
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?