Version 5 (modified by ken@…, 6 years ago) ( diff )

Rework how to fix ntpd failing to sync - problem now attributed to suspend to RAM.


The download URL is

NTPD privsep

Installing ntpd to drop to non-root -

If you have libacl and libattr installed, you can configure NTP with:


Then add an ntpd user:

groupadd ntpd &&
useradd -c 'ntpd PrivSep' -d /var/lib/ntpd -g ntpd \
    -s /bin/false ntpd &&
install -v -m710 -g ntpd -d /var/lib/ntpd

Install the blfs bootscript, and modify /etc/rc.d/init.d/ntp with this:

loadproc /usr/sbin/ntpd --configfile=/etc/ntpd.conf \
                   --jaildir=/var/lib/ntpd --logfile=/var/log/ntpd.log \
                   --pidfile=/var/run/ --user=ntpd:ntpd \

To give the ntpd user minimal privileges create a tmpfs just big enough for the drift file:

install -d -m 0000 /var/lib/ntpd/drift

And add this to /etc/fstab, and replace the gid with ntpd's group id:

tmpfs /var/lib/ntpd/drift tmpfs size=9k,nosuid,noexec,nodev,mode=1770,gid=1003,nr_inodes=2,nr_blocks=2 0 0

Fixes if synchronisation fails following frequent suspend to RAM

On one of my machines, ntp had lost synchronisation. I initially blamed the tsc clocksource in a particular kernel version, and recommended changing it back to acpi_pm.

From the initial version of this section:

On one of my machines, in one kernel release, I lost synchronisation and the log showed:

frequency error 1726 PPM exceeds tolerance 500 PPM

Google found a not-too-old link to redhat [​] which suggested checking the available drivers with

cat /sys/devices/system/clocksource/clocksource0/available_clocksource 

and assuming that acpi_pm is available, temporarily changing to it with

echo acpi_pm >/sys/devices/system/clocksource/clocksource0/current_clocksource 

and seeing if that helps. If useful, it can forced by adding


to the bootargs in grub.

A better fix (sysvinit)

I forgot about the problem, until one day when I discovered that my desktop clock was 5 minutes slow. In the end, 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.


Note: See TracWiki for help on using the wiki.