Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Did anyone encountered leap second issue in rhel 6.3?
We recently had a production outage due to this issue which occurred on 1st Jan 2017 00:00 AM.
It literally spoiled my new-year party and i don't want to encounter this again next year.
Due to product obligations, we can't update the OS and hence need to find out a workaround.
Red-hat documentations says to run ntp in skew mode, i just wanted to know from the community that did anyone encountered this issue and if yes, what workarounds actually worked apart form upgrading the OS?
After the RedHat announcement about this past leap second before it occurred I had done reading that suggested we really only have to worry if we do an absolute time update at exactly midinight UTC when the leap second occurs. Since we had a leap second in 2015 without any noticeable ill effects it seemed likely we wouldn't this time either.
We in fact saw no issues on any RHEL5/RHEL6/RHEL7 server due to this leap second.
If you saw an issue you may want to look into what might be doing an absolute time update at exactly midnight UTC on your system.
I don't think there is much benefit to addressing it now, after the fact. You may need to address it if they announce another coming leap second in future.
rhl 6.4 and above has this issue fixed, we encountered it specifically on rhel 6.3 servers.
This resulted in high CPU utilisation caused because of the java processes and we had to reboot the vms.
Red-hat documentations says to run ntp in skew mode, i just wanted to know from the community that did anyone encountered this issue and if yes, what workarounds actually worked apart form upgrading the OS?
Quote:
Originally Posted by iconmani
rhl 6.4 and above has this issue fixed, we encountered it specifically on rhel 6.3 servers.
This resulted in high CPU utilisation caused because of the java processes and we had to reboot the vms.
I've seen it back on 2015 on a Centos-6.2 running zimbra (that is a java based mailserver). It's actually a java problem, so updating just java (not the whole OS) will solve it.
Anyway at that time there was no java without the leap second issue available, so I had to run the following commands (from here):
The most simple command to clear the leap second flag is
Code:
date -s now
I would simply upgrade the OS to 6.9 or at least 6.4
If this is not an option you can install a 6.4 kernel on 6.3
Hi,
The leap second problem was due to the java version shipped with RHEL-6.2/6.3.
So OP can just update java if upgrading OS is not an option, or else change the time and restart ntpd if needed
Leap second has become a pretty common problem and some of the common issues can be observed during this time are:
- High CPU usage for processes like Java
- Sometimes even VM becomes unresponsive
Resolution:
- To resolve this either we can go ahead with Patching process and if we don't want to go with that then there is another way also.
- Manually resetting the date using below command can also fix this issue.
date -s "`LC_ALL=C date`"
OR
date `date +'%m%d%H%M%C%y.%S'`
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.