Today for the second time since I've owned my OS 6 unit (now on 6.7.1 FW) the NTP process has incorrectly set my device time to a date in the past before correcting itself sometime later.
May 30 09:23:34 DESPAIR connmand[5534]: ntp: adjust (jump): -454753305.317564 sec
Jan 01 00:01:49 DESPAIR systemd[1]: Time has been changed
Jan 01 00:18:53 DESPAIR connmand[5534]: ntp: adjust (jump): +454753299.218670 sec May 30 09:40:33 DESPAIR systemd[1]: Time has been changed
Any idea why this is happening? The servers I used were 0.pool.ntp.org and 1.pool.ntp.org. I've now changed to time.nist.gov but I doubt this is a global issue with the NTP servers in pool.ntp.org otherwise it would be all over the internet.
Thanks...
Model: RN526X| ReadyNAS 526X 6-Bay with up to 60TB total storage
May 30 09:23:34 DESPAIR connmand[5534]: ntp: adjust (jump): -454753305.317564 sec
Jan 01 00:01:49 DESPAIR systemd[1]: Time has been changed
Jan 01 00:18:53 DESPAIR connmand[5534]: ntp: adjust (jump): +454753299.218670 sec May 30 09:40:33 DESPAIR systemd[1]: Time has been changed
I also use 0.pool.ntp.org, and the biggest NTP slew I see for 30 May is about 5 ms. I am wondering if something went south with the RTT estimate built into the protocol?
I will say that the internet connection this device leverages is very slow circa 2Mbps but that should not be an issue for NTP and it's calculation. I will see how we get on with a new NTP server.
I understand that NTPD can be setup to reject huge time offsets and consider these erroneous / ignore them. I believe in future releases Netgear should configure it in this way to prevent this issue from occurring. It can cause all manor of issues.
Well this has happened again even using Netgear's NTP servers:
Sep 22 10:37:25 DESPAIR connmand[5538]: ntp: adjust (jump): -464693790.406618 sec Jan 01 00:00:54 DESPAIR systemd[1]: Time has been changed Jan 01 00:01:16 DESPAIR readynasd[5804]: UpdateRRDVolume failed: ERROR: /run/readynasd/stats/volume_data_int.rrd: illegal attempt to update using time 1041379276 when last update time is 1506073007 (minimum one second step) Jan 01 00:01:16 DESPAIR readynasd[5804]: NetworkStats eth0 failed: ERROR: /run/readynasd/stats/network_eth0_pkts.rrd: illegal attempt to update using time 1041379276 when last update time is 1506073007 (minimum one second step)
Jan 01 00:01:17 DESPAIR readynasd[5804]: NetworkStats eth1 failed: ERROR: /run/readynasd/stats/network_eth1_pkts.rrd: illegal attempt to update using time 1041379277 when last update time is 1506073007 (minimum one second step)
Jan 01 00:01:18 DESPAIR readynasd[5804]: UpdateRRDTemperature failed: ERROR: /run/readynasd/stats/temperature_int_deg.rrd: illegal attempt to update using time 1041379278 when last update time is 1506073007 (minimum one second st ep) Jan 01 00:02:26 DESPAIR smbd[1185]: pam_unix(samba:account): account mark has password changed in future Jan 01 00:05:01 DESPAIR CRON[1215]: pam_unix(cron:account): account root has password changed in future Jan 01 00:05:01 DESPAIR CRON[1215]: pam_unix(cron:session): session opened for user root by (uid=0) Jan 01 00:05:01 DESPAIR CRON[1219]: (root) CMD (/frontview/bin/fvbackup 008 &> /dev/null) Jan 01 00:05:01 DESPAIR CRON[1215]: pam_unix(cron:session): session closed for user root Jan 01 00:05:01 DESPAIR fvbackup-q[6256]: Command: enqueue:8 Jan 01 00:05:01 DESPAIR fvbackup-q[6256]: write(/var/log/frontview/backup/status_backup_008,BACKUP_STATUS__IN_QUEUE!!1041379501!!OK) Jan 01 00:05:01 DESPAIR fvbackup-q[6256]: Push: job_id=8 q_wp=338 q_rp=338 Jan 01 00:05:04 DESPAIR fvbackup-q[6256]: cmd=/frontview/bin/fvbackup -e 8 Jan 01 00:05:04 DESPAIR fvbackup-q[6256]: Create a readonly snapshot of '/data/ADMINISTRATION' in '/data/._share/ADMINISTRATION/.snapshot/b_1041379504_1226' Jan 01 00:05:12 DESPAIR fvbackup-q[6256]: Delete subvolume (no-commit): '/data/._share/ADMINISTRATION/.snapshot/b_1041379504_1226' Jan 01 00:05:12 DESPAIR readynasd[5804]: Successfully completed backup job Backup008 - ADMINISTRATION. Jan 01 00:06:50 DESPAIR smbd[1252]: pam_unix(samba:account): account mark has password changed in future Jan 01 00:17:01 DESPAIR CRON[1357]: pam_unix(cron:account): account root has password changed in future Jan 01 00:17:01 DESPAIR CRON[1357]: pam_unix(cron:session): session opened for user root by (uid=0) Jan 01 00:17:01 DESPAIR CRON[1361]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jan 01 00:17:01 DESPAIR CRON[1357]: pam_unix(cron:session): session closed for user root Jan 01 00:17:59 DESPAIR connmand[5538]: ntp: adjust (jump): +464693784.776433 sec Sep 22 10:54:24 DESPAIR systemd[1]: Time has been changed
Please can something be done to prevent this moving forward!
Currently running 6.7.5. At least this release had the fix which previously screwed up my graphs. But this NTP issue could be very easily resolved to prevent updates with excessive time changes unless the box had just booted.
I will be upgrading to 6.8.x release in the next month or so. This is a business device so I don't upgrade immediately to the latest version.
Does anybody know if Netgear have put a mechanism in place in later releases which prevents massive changes in the system time (unless following a reload / power-on).
I no longer use NTP due to the issue reported in this thread. However, I find these NAS boxes are really bad at keeping time so run it manually occasionally but it is far from ideal
