1

I use the following commands to set the timezone on our Amazon Linux (Centos) server:

ls -al /etc/localtime
-rw-r--r-- 1 root root 118 25 dec  2012 /etc/localtime
sudo mv /etc/localtime /etc/localtime.bak
sudo ln -s /usr/share/zoneinfo/Europe/Amsterdam /etc/localtime

This backups the localtime file, so you can see if and when the time is set to the right timezone. Recently the time has been set back to the default. The bak file is still there, so I know I changed time in the past.

Is this because of a kernel update?

Why doesn't time stay the same and is there a way to make sure it does?

Update

This is the time of the updated localtime file:

$ ls -al /etc/localtime
-rw-r--r-- 1 root root 118 25 jun 19:05 /etc/localtime

Looking at /var/log/yum.log I see this:

Jun 25 19:05:27 Updated: glibc-common-2.17-55.143.amzn1.x86_64
Jun 25 19:05:30 Updated: glibc-2.17-55.143.amzn1.x86_64
Jun 25 19:05:31 Updated: libtiff-4.0.3-20.20.amzn1.x86_64
Jun 25 19:05:31 Updated: glibc-headers-2.17-55.143.amzn1.x86_64
Jun 25 19:05:31 Updated: subversion-libs-1.8.11-1.50.amzn1.x86_64
Jun 25 19:05:32 Updated: subversion-1.8.11-1.50.amzn1.x86_64
Jun 25 19:05:32 Updated: glibc-devel-2.17-55.143.amzn1.x86_64
Jun 25 19:05:32 Updated: libtiff-devel-4.0.3-20.20.amzn1.x86_64
Jun 25 19:05:32 Updated: python26-jmespath-0.7.1-1.9.amzn1.noarch
Jun 25 19:05:32 Updated: python27-jmespath-0.7.1-1.9.amzn1.noarch
Jun 25 19:05:33 Updated: glibc-2.17-55.143.amzn1.i686

So I suspect one of them to do this, one of the glibc updates I guess.

SPRBRN
  • 1,117
  • 2
    It definitely has nothing to do with the kernel. It's more likely to be related to an upgrade of zoneinfo (or whatever it's named on your distribution). – lcd047 Jul 07 '15 at 08:30

1 Answers1

2

Look at the ls -l /etc/localtime to see at what time the change happened. Then look through logs such as /var/log/audit/audit.log and /var/log/secure for what might have started at around that time.

Note that now systemd has taken over /etc/localtime and there is a command 

timedatectl set-timezone <zone>

that can change this file too. Also, there is a systemd-timedated.service which provides a dbus service to change the timezone. You can also look through the systemd logs:

sudo journalctl -l|grep timedate

You can find what scripts are run by the installation of an rpm by running 

rpm -q --scripts glibc

for example for glibc. You can log the changes in a file by installing and starting audit and configuring a watch on the file with

sudo auditctl -w /etc/localtime -k mymarker

then looking through the logs with

sudo ausearch -k mymarker

Remove all rules with sudo auditctl -D. You will get info on any process that opens or changes the file, but if it is from a shell script that wont help much, as the command will just be rm or ln.

Perhaps if you use timedatectl set-timezone to change the timezone instead of linking it yourself it will do it in a way that further updates will accept and not change.

meuh
  • 51,383
  • I've updated my question, and linked it to the yum log. I can set a cron script to check the time and renew the symlink, but is that the way to handle this? – SPRBRN Jul 07 '15 at 09:46
  • @SPRBRN Until you find out the real problem, that's a good practical solution. I added some info on rpm and audit to my answer. Also, perhaps if you use timedatectl set-timezone to change the timezone it will do it in a way that further updates will accept and not change. – meuh Jul 07 '15 at 10:39
  • I'm aware of systemd, but don't think we're using it on our servers, and I don't know how to check it. (I can't believe we use it as this would have resulted in configuration changes.) However, that info is probably useful for others, so good to know. – SPRBRN Jul 07 '15 at 12:34
  • Just found this answer here: http://unix.stackexchange.com/a/196183/34756 and we're still using init.d! – SPRBRN Jul 07 '15 at 12:37