I decided to write about handling the time at UNIX/Linux systems because a message like this:
[29071122.262612] Clock: inserting leap second 23:59:60 UTC
I have similar logs in my servers last June 30, 2015. Of course, I was aware about it some months before and I have to do some work to be ready (kernel/ntpd upgrades depending on the version of the package, we work with 8 main releases of 3 GNU/Linux distributions). In previous leap seconds some issues affected to Linux servers all around the world. As I was praying for it, nothing happened after the leap second insertion, and I went to sleep deeply. But that has been one of the rare situations in which having different tiers (development/integration/staging/production) doesn’t means nothing because you test all the environments at the same time.
Ok, let’s go. We need an accurate time for a server. It’s important -specially, in database servers. So we will use the NTP daemon. In RHEL7 we could use chronyd, but the recomendation for servers with a stable time source is using ntpd.
But, of course, if we didn’t it before (maybe in the OS installation) we will need to adjust the time zone.
In previous RHEL/SLES major releases we must edit /etc/sysconfig/clock:
But this configuration requires rebooting the node, and sometimes it’s not possible. So, in order to take effect imediately, we run this command:
root@tardis:~ # ln -s /usr/share/zoneinfo/Europe/Madrid /etc/localtime
In SLES of course you can use YaST for this task too.
If we are working on RHEL7/SLES12, we need to deal with Skyne^W^W systemd. And it’s easy, we only need running:
root@tardis:~ # timedatectl set-timezone Europe/Madrid root@tardis:~ # timedatectl Local time: mar 2015-08-11 16:29:00 CEST Universal time: mar 2015-08-11 14:29:00 UTC RTC time: mar 2015-08-11 14:29:00 Time zone: Europe/Madrid (CEST, +0200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at dom 2015-03-29 01:59:59 CET dom 2015-03-29 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at dom 2015-10-25 02:59:59 CEST dom 2015-10-25 02:00:00 CET
root@tardis:~ # timedatectl list-timezones Africa/Abidjan Africa/Accra Africa/Addis_Ababa Africa/Algiers Africa/Asmara Africa/Bamako ...
There is a peculiar case with the Oracle Exadata product. The first time you face this hardware+software stack, maybe will be tempted to manage it like another RHEL server. But if you read the Exadata documentation (you have the PDF’s in /usr/share/doc…) you’ll see there are additional consistency layers (so be careful installing packages from other distributions ;-)).
For example, at the storage cells you will stop the services, and run the /opt/oracle.cellos/ipconf utility. When you finish the changes are reflected at the usual config files and at /opt/oracle.cellos/cell.conf
... <Ntp_drift>/var/lib/ntp/drift</Ntp_drift> <Ntp_servers>ntpserver1</Ntp_servers> <Ntp_servers>ntpserver2</Ntp_servers> <System_active>non-ovs</System_active> <Timezone>Europe/Madrid</Timezone> <Version>220.127.116.11.0</Version> ... </Cell>
(It’s a 11.2 cell xml configuration file; the new releases have a different sintax)
At the compute nodes the configuration change must be done at /etc/sysconfig/clock, but you must stop and disable the crs before the change.
Here is the full configuration guide for Exadata 12c RC1 components.
In HP-UX 11.11, 11.23 and 11.31 the timezone configuration resides at the /etc/TIMEZONE script:
TZ=MET-1METDST export TZ
There are two parameters, timezone and dst at kernel level you can touch for legacy applications. They are no longer used.
In AIX the standard method for configurations is using smit. So you can run smitty and go to the System Environments menu. The changes are reflected in the file /etc/environment
AIX 7.1 and AIX 6.1
... TZ=Europe/Madrid LANG=C LOCPATH=/usr/lib/nls/loc ...
... TZ=CET-1CEST,M3.5.0,M10.5.0 LANG=en_US LOCPATH=/usr/lib/nls/loc ...
You will get noticed in AIX 5.3 the configuration is a bit more complex. In this version you must configure the DST, etc. There is a guide at IBM’s web.
In the next chapter I will cover ntpd administration.