Fixes if synchronisation fails following frequent suspend to RAM

On one of my machines, ntp had lost synchronisation. This appears to be related to frequent suspend to RAM, sometimes for a few days. In early versions of pm-utils (which is what I use for s2ram) there was a script to fix up ntpd - but that was removed long ago, in the belief that the clock would only drift for a maximum of 64 seconds realtime (not drift *by* 64 seconds!) and then ntpd would start to sync it. For systemd the preferred methods are apparently different. Anyway,I've now added the following script as /usr/lib/pm-utils/sleep.d/48ntpd (mode 755) and things seem to work - using 'ntpq -p' I can sometimes see offsets of several hundred milliseconds (and increasing!) even when the box has sync'd to my local server, but it seems to stay accurate to within a second, and eventually syncs to a few milliseconds.

# stop ntpd on suspend, fix and start fresh on wakeup


case $1 in
        /etc/rc.d/init.d/ntpd stop
        /usr/sbin/ntpd -gq
        /etc/rc.d/init.d/ntpd start
    *) exit 0 ;;
exit 0

When the clock is too far away from the correct time

If ntpd bails out because the clock is too far from the correct time, try stopping ntpd, then use

ntpd -gq

to let it sync, and then restart ntpd. According to the man page, -g can be used multiple times if the clock is far adrift.

Last modified 4 months ago Last modified on 12/19/2023 08:35:20 PM
Note: See TracWiki for help on using the wiki.