Redhat leap second patch

There are couple of other mitigation steps or options that one could implement to handle the leap second event.. The nptd documentation indicates the default for stepout is If "tinker stepout X" is specified in ntp.

It cannot serve as a public NTP server" instead of "When the leap second occurs, this systems time will be stepped by the kernel. So I think the script is looking for "step" and incorrectly matching "stepout".

If this is correct can this be fixed? You are right. The script matches "stepout" while looking for "step". It is corrected and published as 1. Retired: This application is now retired. Comments 41 Related Content List. The app is out of date. We will update it for next leap second event. Subscriber exclusive content An active Red Hat subscription is required to participate.

Log In. Dave Ritchie. RW Red Hat. Rex White. Red Hat Guru points. Ranjith Rajaram. Christian Horn. TU Newbie 4 points. Tenet UNIX. Sham Antony. EB Community Member 30 points.

Edward Brand. Feature Request: Its much easier to check exit status rather then parse output when running on thousands of servers. Newbie 9 points. Ramkumar Chinnu. Dong Zhao. Thanks for your patience. Thanks Dong for your prompt response. Script has been updated for JJ Newbie 10 points.

Jiri Jevicky. Yes, this url works. So assuming the Linux kernel team has fully resolved the problem, and you've updated your kernels since , it should not reoccur. Personally I'm encouraging an internal test at Splunk Corporate for the leap second traversal now. We can't cover all cases, but we should cover the common one.

Your answer goes some way toward helping me understand workaround specified in the item where you're supposed to stop ntp, execute date , and then restart ntp.

BTW, I've also opened an issue with Splunk to get the official line on this, and we'll see what they come up with. Sign In. Turn on suggestions.

Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type. Showing results for.

As mentioned previously, the leap second must be skipped when the system is using UTC, as this second does not exist. Therefore, to prevent the system clock from being one second ahead of UTC, the clock must be corrected after the leap second occurs. This correction may occur in a variety of ways, outlined below:. The default approach by most daemons is to notify the kernel, and allow it to insert the leap second. For instance, during the last day before a leap second correction NTP servers should notify their clients that a leap second will occur, and at UTC, the Linux kernel should add or remove an extra second by making the 60th second occur twice or removing it entirely.

Thus, Red Hat Enterprise Linux systems running an NTP client, with a default configuration, during the last leap second correction should have counted time as follows:.

Instead of notifying the kernel, and allowing it to step the time back, the daemon may step the system clock backwards. Time will be counted similarly to the kernel inserting the leap second; however, as the daemon performs the actual insertion any bugs specific to the kernel will not be encountered. RHEL 6. This slew is handled as a one-second offset accumulated at UTC, for leap second insertions, or UTC, for leap second deletions, that is smoothed out over time.

This method may be preferred over stepping when applications running on the system are sensitive to jumps in system time and it is acceptable that the clock will be off for a longer time. Instead of addressing the leap second daemons may be configured to ignore it entirely, allowing time to be slowly corrected as any other unexpected change in time. The clock will continue with the incorrect time until it is addressed through normal operation.

If multiple systems are configured with this method it is possible that their times will drift apart from each other, as the correction process is random to a certain extent. This method is not recommended for systems that require in-sync communication. Instead of having the clients slew the leap second, it may instead be suppressed on the server and slowly correct the served time by slewing the leap second instead of stepping it.

Clients do not need any special configuration, as they do not know there is a leap second, and will continue to follow the server time until they are in sync with UTC. Smearing the leap second on the server is much slower than doing so on individual clients; however, it allows all clients to connect.

When configuring a NTP server to smear the leap second it is necessary to ensure that all clients using it are only pointing to servers that are performing the smear in an identical fashion.

If clients are configured to receive updates from multiple servers, and these servers handle the leap second in a different fashion, inconsistent results will occur. A list of example configurations may be found at the bottom of this page, in Example Configurations.

After the leap second, there were 24 leap seconds added since the Epoch. A system restart is not required after this update; however, if any applications are caching results from these functions then these applications may need to be restarted after tzdata has been updated.

Note: Red Hat does not recommend running without a source of time synchronization enabled as there is no guarantee that systems will remain in sync with each other. Time drift may occur on each system as determined by its clock source. By default, Linux systems not using NTP or PTP to synchronize their timekeeping will not correct for leap seconds, and the time reported by these systems will have a one-second difference relative to UTC after the leap second correction.

You should reset the clock manually after leap seconds occur. In addition to the issues tracked above it is possible that application-specific issues will arise if the leap second was not considered during development. Issues of this nature are documented in Libraries and Applications do not account for the Leap Second. A separate article has been created for tracking issues with realtime kernels. Red Hat continues to test for any issues, and as information is available regarding the completed tests this article will be updated.

A lab has been developed to perform this test, and is available at Leap Second Issue Detector. In addition, Red Hat strongly recommends that customers test their builds and environments, and instructions on how to test, including a sample program to do so, are provided at Are we susceptible to a leap second event?

These options will instruct chronyd to correct the system clock by stepping the leap second, bypassing any bugs with the kernel's insertion of the leap second. These options will instruct chronyd to correct the system clock by slewing the leap second instead of stepping back immediately. These options will instruct chronyd to correct the system clock by slewing the leap second and limit the slewing rate of the local clock to parts per million ppm. With this flag added the kernel's leap second correction is disabled, and the leap second will be corrected over a period of time.

Additional information on leap seconds and how they are handled in Linux and by NTP can be found at the following links:. What is the issue in kernels prior to version kernel All of my tomcat6-on-RHEL6 servers froze. Restarting services doesn't help and disabling NTP doesn't do anything. Splunk is freaking out and causing issues for me. All of the RHEL5 boxes are fine. I ran "uptime" against my RHEL6 boxes using mcollective, and all the servers are at a load of 5 or higher.

What a mess. So I'm pretty certain this is related. Thanks a ton Pedro Alves! Does anyone know if there are other side effects of this issue and whether the date commands listed above will fix them too?

Manually updated the latest tzdata rpm to "tzdataa But I am not sure how to test this fix as it working fine. Any help or suggestion that how to confirm that the upgrading to the latest rpm and modifying the localetime link will fix the leap second issue.

Hi, I guess, there was misunderstanding. First of all you are not using ntp so you will not see that whether ntp has aligned to issue a leap second or not locally using ntpq command. You can verify it using zdump command to see if system will feel leap second or not. For me IST. I have this same suspicion. Latest tzdata RPM "tzdataa Now to check the vulnerability used the " Leap Second Vulnerability Detector" tool and the result says "Not vulnerable". Now we are confused as zdump output says leapsecond is coming and the "Vulnerability Detector" tools outputs says we are safe.

Detector tool just check whether we have latest packages updated or not which handle leap second properly. If it detect package which do not handle it properly, it will show it is vulnerable.

What does "ntpd -x" mean? Can I run NTP in slew mode? Does Red Hat plan to release xleap. Plan B is faster. That's all. In that case, could you help me understand how the leapsecond-flag in the kernel would get cleared? With the flag set, the kernel is handling the leapsecond, from what I see. Hi Christian. Is not big deal.

Already talk to RedHat support. Forget about the flag. You turn it on a few hours later and that's it. And as we confirmed with the 3rd party vendor they will insert a leap second at June 30th, at UTC. Can someone help to clarify below concerns. To avoid any impact to all clients is it safe to run the NTP server within our premise in slew mode? If we enable slew mode in server side does all client also need to be changed to slew mode?

As confirmed with Redhat in a separate case , if the kernel versions are updated to the recommended level then we shouldn't hit the OS crash issue when leap second insertion occur.

However High CPU can occur for some applications irrespective of kernel version or ntp package version , Can slew mode can be used to avoid this situation?

Any other tips to better handle this situation would be much appreciated. According to RH support tests the cron jobs scheduled on will not be affected and should run just once as expected. I am under the impression from the redhat article that if running ntp client that I should not worry about a kernel crash. But what I am reading in the posts is that if the kernel is not updated to the latest version, then when the leap second happens, this could cause a kernel crash. Do i need to stop ntp and restart after the leap second happens or run ntp in skew mode, or just keep ntp running and hope that no kernel crash happens.

Now guys could someone correct do we need to go for a or d version and how to get only the version related to leap second issue may be a? Newer tzdata include changes which arrived in previous versions if those are still valid, of course Actually Redhat mentioned a package across all leap second articles so worried after looking at change log on that particular packages.

Is there is new tzdata package for RHEL4 or is the latest tzdata for v4 rpm -qa grep tzdata tzdatan For RHEL4, the latest ntp tzdata package is tzdatad