Bug 858847 - chrony getting weird times from server seemed to cause a reboot.
chrony getting weird times from server seemed to cause a reboot.
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: chrony (Show other bugs)
17
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Miroslav Lichvar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-19 15:25 EDT by Stephen John Smoogen
Modified: 2013-04-25 10:08 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-25 10:08:16 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen John Smoogen 2012-09-19 15:25:11 EDT
Description of problem:
chrony getting weird times from server seemed to cause a reboot.

This morning my Lenovo T520 laptop rebooted in the middle of work. Looking through the logs post reboot I found the following weird clock changes that occurred at time of the reboot

Sep 19 09:44:19 seiji dnsmasq[1059]: using nameserver 205.171.2.25#53
Sep 19 09:44:19 seiji dnsmasq[1059]: using nameserver 192.168.0.1#53
Sep 19 09:44:21 seiji systemd-logind[893]: Removed session 1.
Sep 19 09:44:22 seiji systemd-logind[893]: New session 2 of user smooge.
Sep 19 09:44:22 seiji systemd-logind[893]: Linked /tmp/.X11-unix/X0 to /run/user/smooge/X11-display.
Sep 18 09:44:23 seiji chronyd[914]: Selected source 148.167.132.200
Sep 18 09:44:23 seiji chronyd[914]: System clock wrong by -86400.231763 seconds, adjustment started
Sep 18 09:44:23 seiji chronyd[914]: System clock was stepped by -86400.232 seconds
Sep 18 09:44:23 seiji kernel: [   63.317223] fuse init (API version 7.19)
....
The time then tries to go forward 24 hours in 10 minutes... and then goes 48 hours in time with 

Sep 18 18:05:27 seiji smartd[851]: smartd received signal 15: Terminated
Sep 18 18:05:27 seiji smartd[851]: smartd is exiting (exit status 0)
Sep 18 18:05:27 seiji kernel: Kernel logging (proc) stopped.
Sep 18 18:05:27 seiji rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="901" x-info="http://www.rsyslog.com"] exiting on signal 15.
Sep 20 04:40:36 seiji kernel: imklog 5.8.10, log source = /proc/kmsg started.
Sep 20 04:40:36 seiji rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="876" x-info="http://www.rsyslog.com"] start
Sep 20 04:40:36 seiji udevd[462]: specified group 'plugdev' unknown

ep 20 11:47:01 seiji dbus-daemon[923]: Starting iscsi (via systemctl):  [  OK  ]
Sep 20 11:47:07 seiji NetworkManager[866]: <info> Starting VPN service 'vpnc'...
Sep 20 11:47:07 seiji NetworkManager[866]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 2146
Sep 20 11:47:07 seiji NetworkManager[866]: <info> VPN service 'vpnc' appeared; activating connections
Sep 19 11:47:08 seiji chronyd[909]: Selected source 96.44.142.5
Sep 19 11:47:08 seiji chronyd[909]: System clock wrong by -86400.118326 seconds, adjustment started
Sep 19 11:47:08 seiji chronyd[909]: System clock was stepped by -86400.118 seconds

Not sure what was the cause of this altogether.. I went through the system hardware logs and didn't find any errors about clock or cpu etc during that time.


Version-Release number of selected component (if applicable):
chrony-1.27-0.3.pre1.fc17.x86_64

How reproducible:
Not

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Miroslav Lichvar 2012-10-09 09:25:37 EDT
That's odd. Was the clock correct before or after the first 24 hour jump? Do you have any custom script setting the system clock, for example a cron script calling hwclock?
Comment 2 Stephen John Smoogen 2012-10-09 15:04:37 EDT
The clock looked correct in the times in the logs before the jump. After the jump it was not. I do not have anything different from a default Fedora 17 install on the system. In the logs I do not see chrony syncing with any other clock.. is that normal?
Comment 3 Miroslav Lichvar 2012-10-10 04:28:18 EDT
I'm not sure what is going on here. Both 148.167.132.200 and 96.44.142.5 seem to serve correct time now. Can you please enable the measurements logging in chrony.conf in case this happens again?

I'd suspect some problem with timezone and RTC, but 24 hour error is too large for that I guess. Does hwclock --show show correct time?
Comment 4 Stephen John Smoogen 2012-10-10 13:44:33 EDT
hwclock states it was correct. I did check that after I determined the system had crashed because of the time issue. I have heard that there have been some hacker clans going around changing ntp clocks on systems for lols after the last set of crashes from the leap second.. but who knows. I guess I need to figure out a way to make a clock reverse.
Comment 5 Miroslav Lichvar 2013-04-25 10:08:16 EDT
I'm closing this bug, as there really is not enough information to find out what's going on. Please reopen if this happens again and there is more information available.

Note You need to log in before you can comment on or make changes to this bug.