Description of problem:
When the system leap status is set in the last day of the month to insert/delete a leap second and the upstream NTP sources later in that day fail to reach majority on the leap second, the leap second timer will be disarmed, but the system leap status will not be reset and the leap second will still be announced to NTP clients.

If not using the -x option, the kernel will step the clock back by one second at midnight even when the sources no longer agree there is a leap second in that day. ntpd will keep setting the kernel leap status and the next day the clock will be stepped again. This incorrect step will be corrected later by forward step, which will finally reset the system status to the normal non-leap value.

If using the -x option, the ntpd instance will continue to announce the leap second to its clients until the service is restarted and the clients may apply it every day/month/6 months depending on their implementation. 

Version-Release number of selected component (if applicable):
ntp-4.2.6p5-20.el7

How reproducible:
always

Steps to Reproduce:
1. configure ntpd with a server that simulates a leap second on the last day of a month
2. wait until ntpq -c rv reports leap=01
3. turn the leap status on the server off
4. monitor ntpq -c rv output

Actual results:
leap not reset to 00

Expected results:
leap reset to 00

Additional info: