Retired: This application is now retired.
Leap Second Issue Detector (OUT OF DATE)
The app is out of date. We will update it for next leap second event.
This script helps you test whether your system is subject to the leap second issue. The next leap second will occur on 2016 December 31, 23h 59m 60s UTC.
21 Comments
Subscriber exclusive content
An active Red Hat subscription is required to participate.
Log In'Signed for your protection' gives me no confidence when the verification output produces '...output similar to this:' '...gpg: WARNING: This key is not certified with a trusted signature!
...'
I agree, but the problem is that to get rid of that warning you would have to assume that the key you downloaded from pgp.mit.edu hasn't been tampered with. Is that a safe assumption? Probably, but I can't make that decision for the user. Ultimately, they are going to have to download a key from somewhere and trust that it's valid, unless someone hands them some physical media with a key on it. The first two lines DO say:
gpg: Signature made Mon 23 Feb 2015 12:22:15 PM EST using RSA key ID 8366B0D9
gpg: Good signature from "Red Hat, Inc. (tools key) "
which indicates that the file WAS signed with the key that was downloaded.
As per my understanding, tzdata package update is not required if you have ntpd. Script checks for tzdata and kernel.. Does not check whether the customer is running ntpd. Inspite of having ntpd running, script makes the tzdata package update recommendation
I have opened (private) bz1207630, requesting to either also check NTP connectivity or clearly state that this verification script here is aimed at standalone systems without means to receive the leapsecond-info from somewhere else.
The leap_vulnerability.sh script fails when the uname -r output is formatted as follows:
2.6.18-308.1.1.0.1.el5
One of our RHEL 5.7 systems is using this level. It appears this piece of code should account for 6 items in the minor part of the uname -r output:
if [ "${#minor[@]}" -eq "2" ]; then
compareString=${minor[0]}'.0.0'
elif [ "${#minor[@]}" -eq "3" ]; then
compareString=${minor[0]}'.0.0'
elif [ "${#minor[@]}" -eq "4" ]; then
compareString=${minor[0]}'.'${minor[1]}'.0'
elif [ "${#minor[@]}" -eq "5" ]; then
compareString=${minor[0]}'.'${minor[1]}'.'${minor[2]}
fi
The script leap_vulnerability.sh is not able to download with curl/wget, getting a html file instead of actual script. But getting actual script when downloading it via browser.
Sham, this works for me here. Please note that curl/wget need to authenticate directly or use a cookie. There are browser plugins who instead of downloading generate a "curl" commandline with parameters which take over that part.
Feature Request:
Its much easier to check exit status rather then parse output when running on thousands of servers.
Can the leap_vulnerability.sh li be updated to exit 1 if issue is found.
That's an excellent point! I've passed it on to the owner of the script. That functionality should show up in the next version (8.5)
Hello, This is same script can identify for Leap Second 2016 ? or any progress for new script ! Thanks Ram
Hi Ram, We are working to update the script for the upcoming leap second event. Please stay tuned!
Thanks Dong Zhao. We are waiting for a long time to get Leap Second detector script from red hat this time. Last Year we got it earlier and it was helpful to get downtime to patch all our servers. Now already too late as far my understanding :) Is there any update for the progress. or can you have any suggestion like 2015 Leap second detector help for current 2016 issue ! Thanks
Hi Ram,
We've updated the script, and we are now testing it.
We will coordinate necessary updates to related KCS. Once all these done, we will publish the script in this app. We will also try to see if we can release the script sooner.
Thanks for your patience. Dong
Thanks Dong for your prompt response.
Hi, So how many days still red hat needs to publish leap second detector script 2016 ! Thanks Ram
Script has been updated for 2016
Hi. I'm getting error page 404, when trying to dowload the https://access.redhat.com/labs/leapsecond/leap_vulnerability.sh
Do you know, where could be problem?
Can you try this url https://access.redhat.com/labs/leapsecond/leap_second_issue_detector.sh
Yes, this url works. (so perhaps you can update link at the top of this page) Thanks.
jiri,
Where do you see the old link ?.
https://access.redhat.com/labs/leapsecond/
The above original content was updated few minutes before my first reply to your comment. I tried searching for stale links. Did find any. Can you check whether you still see the old script references ?
Hi,
RHEL4(2.6.9-106.EL) servers syntax error on the '+=' assignment operator in the 2016 version. Iirc, the '+=' operator isn't bash-3.00 compatible.
I don't suppose it can be made old server friendly.
Thanks!
Justin, Can you try the latest leapsecond issue detector script. The latest version is 1.0.3. It has been corrected.
Hi!
I get this output when running the test script:
"[root@el02cn01 ~]# ./leap_second_issue_detector.sh [INFORMATION] - Installed kernel version: 2.6.39-400.278.1.el5uek - The system is running NTP: ntp-4.2.2p1-18.el5_11.x86_64 When the leap second occurs, this systems time will be stepped by the kernel. Thus, it is configured to stay in sync with the true/official time.
If you would like to learn more on how to resolve Leap Second Issues in Red Hat Enterprise Linux, refer to https://access.redhat.com/articles/15145."
It doesn't exactly match any of your alternatives for output from the script. It almost matches the not affected alternative except the last sentence about resolving the issue. The difference is that it runs ntpd and not chronyd. Does this system require any action or not?
Rgds Christian
I get the same result with an older kernel, isn't clear whether it is effected. Running on RHEL 5.6
./leap_second_issue_detector.sh[INFORMATION] - Installed kernel version: 2.6.18-408.el5 - The system is running NTP: ntp-4.2.2p1-18.el5_11.x86_64 When the leap second occurs, this systems time will be stepped by the kernel. Thus, it is configured to stay in sync with the true/official time.
If you would like to learn more on how to resolve Leap Second Issues in Red Hat Enterprise Linux, refer to https://access.redhat.com/articles/15145.
thanks
Allan, There is no action required. Kernel package and NTP package are above the minimum package level 1. Kernel: minimum version: kernel-2.6.9-89.EL. 2. NTP: minimum version: ntp-4.2.2p1-9 Leap second will be inserted or the system clock will be stepped back on Dec 31 12:59:59 UTC
Christian, Kernel installed on the system is not supported by Red Hat. We will not be able to confirm whether the kernel has allthe required kernel patches to handle leapsecond event. Since the system is running NTP, leapsecond willbe inserted on Dec 31 12:59:59 UTC.
Another similar example:
"[root@ska711 ~]# ./leap_second_issue_detector.sh
[INFORMATION] - Installed kernel version: 2.6.18-194.3.1.el5PAE - The system is running NTP: ntp-4.2.2p1-9.el5_3.2.i386 When the leap second occurs, this systems time will be stepped by the kernel. Thus, it is configured to stay in sync with the true/official time.
If you would like to learn more on how to resolve Leap Second Issues in Red Hat Enterprise Linux, refer to https://access.redhat.com/articles/15145."
Does this last sentence "If you would like to learn more ...." mean that the system is affected? It would have been good if the test had stated clearly if any action is required or not.
Rgds Christian
Last line "If you would like to learn more on how to resolve Leap Second Issues in Red Hat Enterprise Linux, refer to https://access.redhat.com/articles/15145."
I will check with the maintainer. We have captured an example output of the script that gets printed for the affected systems. In the example output for un-affected system and in the above output that you have shown, script actually prints an additional line.
We would still may want to have the last line printed in the console output as a FYI. There are couple of other mitigation steps or options that one could implement to handle the leap second event.. like slew mode, daemonstep, smear etc etc
It seems like the slew detection isn't working correctly in 1.0.3.
The nptd documentation indicates the default for stepout is 900. If "tinker stepout X" is specified in ntp.conf and X is any value including 899 or 901, the script prints "NTP is running slew mode. It cannot serve as a public NTP server" instead of "When the leap second occurs, this systems time will be stepped by the kernel. "
It doesn't seem reasonable that NTPD would change to slew mode if I change stepout by 1 second. 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.0.4.