ntpdate is even easier…

And doesn't do anything close to what ntpd (or opennntpd) does.

They both set the time, sure. But they don't do it in a similar fashion.

@kbrantley:

They both set the time, sure. But they don't do it in a similar fashion.
Of course, openntpd and ntpd have some differences in algorithms used to set the time as well, though far from the apples to oranges comparison with ntpdate (which I agree is completely different and not comparable).

Both openntpd and ntpd support the common wire protocol, but for example, I believe it wasn't until 4.4 that openntpd included frequency adjustment as opposed to raw time adjustment, so you'll want a current version if you prefer that. I believe for the OP that means using a later version than the repository (the version isn't shown, but from the description it sounds pre-4.4). It looks like no Debian (or Ubuntu) repository has later than 3.9.

Which may be preferable is a personal choice, but they aren't necessarily identical (in terms of drop-in replacement), certainly with the version of openntpd currently in the Debian-based repositories.

– David

I was using ntpdate in a cron job every few hours and the clock was drifting a few tenths of a second to a half second. Now with openntpd the clock stays within a few hundredths of a second.

And ntpdate is still installed (but not running in the cron job anymore), so I've been checking the drift:

ntpdate -q -p 8 216.218.192.202 216.218.254.202 209.81.9.7 207.200.81.113 64.125.78.85

The IP's being nearby time servers to the Fremont data center.

ntpdate -q -p 8 216.218.192.202 216.218.254.202 209.81.9.7 207.200.81.113 64.125.78.85
server 216.218.192.202, stratum 1, offset -0.011127, delay 0.02591
server 216.218.254.202, stratum 1, offset -0.010859, delay 0.02739
server 209.81.9.7, stratum 1, offset -0.010878, delay 0.02660
server 207.200.81.113, stratum 1, offset -0.005067, delay 0.02756
server 64.125.78.85, stratum 1, offset -0.011132, delay 0.02769
27 Jun 16:27:22 ntpdate[25023]: adjust time server 216.218.192.202 offset -0.011127 sec

Some basic Unix clock stuff..

Unix expects the clock to always go forward in time. Never should it go backwards (remember, also, the Unix clock is in seconds past 1/1/1970 UTC - your local timezone is just a display interpretation so things like daylight savings don't actually matter to the kernel).

If you run "ntpdate" from cron every so often then you run the risk of the clock doing something like

1:59:59

2:00:00

1:59:59

2:00:00

2:00:01

Which is a really bad thing. Programs might end before they start; jobs might get run twice. Files might be dated in the future. Dogs and cats living together… bad stuff.

A second attribute of the unix clock is that it's meant to be "smooth". 1 second is meant to be 1 second long. Not 0.98 seconds. Not 1.02 seconds. 1 second.

So what ntpd does is calculate how far off your clock is from the server and then tells the kernel about the offset using adjtime(). The Linux kernel will then slowly adjust the clock until that error is zero. It makes approx a 5ms change every second; so the clock is always going forwards but 1 Unix second may be 0.995 real seconds, or 1.005 seconds. A lot better than ntpdate and 1 second is "close enough" for most purposes. Downside: if your clock is too far wrong then it can take a long time for the clock to come back into sync (which is why it's not unknown to call ntpdate in the boot sequence).

Now, according to db3l (I don't know this; I've never used the program) pre v4.4 of openntpd didn't call adjtime() to do the clock changes; it set the clock directly. This is better than calling ntpdate every hour or two but only because the time-jumps are smaller. The clock can still go backwards, time is a lot more jagged and you can't rely on 1 second being 1 second long.

To be honest I don't think this "saw tooth" behaviour is going to be too important to a linode for most people (quanta on a virtual machine is difficult enough as it is!) but from a purist's perspective using a saw tooth correction algorithm is just wong :-)

To the OP: what problem were you seeing with the default ntpd binding to each interface?

@sweh:

Now, according to db3l (I don't know this; I've never used the program) pre v4.4 of openntpd didn't call adjtime() to do the clock changes; it set the clock directly. This is better than calling ntpdate every hour or two but only because the time-jumps are smaller. The clock can still go backwards, time is a lot more jagged and you can't rely on 1 second being 1 second long.
Not quite. It uses adjtime for time updates but doesn't attempt to offset for frequency drift. Under BSD, openntpd versions >= 4.4 use adjfreq for that, but that's not available under Linux, so I think I was wrong and even if you have 4.4+ you won't get that under the Linux port. I'm not that familiar with it, but I believe there's a special kernel discipline under Linux that ntpd uses for drift correction.

So incremental updates to the clock (based on the ntp protocol) will occur smoothly, with no risk of moving back in time, but there's no offset for clock frequency drift, which means that systems with slow/fast clocks will consistently drift in between updates. If, instead, the frequency of the clock itself can be adjusted, that in turn helps ensure accurate timing in between updates, and then minimizes actual adjtime changes.

Note that the difference between something like ntpdate and either of openntpd/ntpd is major. The additional gain from frequency drift correction is a much finer difference. So I don't want to over-emphasize it, but it is a difference between the two implementations under Linux.

> To the OP: what problem were you seeing with the default ntpd binding to each interface?
I'm not the OP, but it is true that the reference ntpd will bind to all the individual interfaces (and default) and at least in Ubuntu's default config (not sure about Debian proper) will accept time queries on those interfaces, though not peering or updates. So without a firewall in place, you are opening up a bit compared to not running ntpd. That can be changed by updating the default configuration, but actually stopping it from listening on all interfaces is a little tougher, depending on version.

– David

@sweh:

…

To the OP: what problem were you seeing with the default ntpd binding to each interface?

Thank you for the Unix clock info. That was all new info for me.

Originally, I had ntpdate via cron and then read some posts here that with the latest paravirt kernels one should use ntpd/openntpd to keep the clock in sync.

I tried ntpd, but didn't like it binding to all network interfaces. I googled, but could not find any way to disable that default behavior.

I read that openntpd is a good drop-in replacement for ntpd if you don't want to run a time server or do some of the more esoteric stuff that ntpd can do. I also liked the default not to bind to any network interfaces of openntpd.

@db3l:

…

Not quite. It uses adjtime for time updates…

So incremental updates to the clock (based on the ntp protocol) will occur smoothly, with no risk of moving back in time…

Note that the difference between something like ntpdate and either of openntpd/ntpd is major.

…

So you've helped support my argument for openntpd. Thank you! :wink:

Last time I got annoyed by this, I dug around too…I seem to recall someone had prepared a patch for ntpd to allow configuring which interfaces it listened on. The developers were pushing back on it for some compatibility reason.

@jed:

Last time I got annoyed by this, I dug around too…I seem to recall someone had prepared a patch for ntpd to allow configuring which interfaces it listened on. The developers were pushing back on it for some compatibility reason.
It looks like the new "interface" command in 4.2.6 should, I think, go a long way to handling this. You need it to at least accept packets on one interface to get responses back from its own peers, but should be able to lock it down much further than the default, or what the earlier "-I" command line option allowed. However, looks like only testing/unstable in Debian repositories have 4.2.6 - none of the Ubuntu repositories do. So you'd likely need to compile it locally to take advantage of that.

Just adjusting the access controls to disallow even time queries should accomplish much the same thing even if it will still bind to all the interfaces. Of course, I would hope most Linodes are firewalled on their public interfaces, so ensuring the protection includes the ntp port pretty well takes care of that. There's not much in terms of resources or anything used even if the ntpd process binds a few extra sockets.

– David

Since I was trying to set up ntpd to listen on only some interfaces, I must say, the interface option behaves somewhat unfriendly so I post my configuration for others fighting ntpd.

Good thing is that ntpd 4.2.6 (in Gentoo unstable repository) is reporting which interfaces it binds to including its behavior (ntpd can listen on an interface but ignores all packets).

interface ignore 0.0.0.0 # Masks out both IPv4 and IPv6 wildcard.

interface ignore :: # Seems to be redundant.

interface listen localhost # Binds to both IPv4 and IPv6

interface listen 178.79..

interface listen 2001:470::::1

You can't use named hosts even if you have address translation in your hosts file (ntpd most likely thinks of it as interface name and fails).

Another issue I encountered was deleting IPv6 addresses for no good reason so I turned off interface updates (-U 0). After that, it finally works.

Here's my full configuration for those interested. If you see some error, let me know.

/etc/conf.d/ntpd (Gentoo specific):````

/etc/conf.d/ntpd

Options to pass to the ntpd process

Most people should leave this line alone …

however, if you know what you're doing, feel free to tweak

NTPD_OPTS="-g -U 0 -u ntp:ntp"

/etc/ntp.conf````
driftfile /var/lib/ntp/ntp.drift

interface ignore 0.0.0.0
interface ignore ::
interface listen localhost
interface listen 178.79.***.***
interface listen 2001:470:***.***::1

server 158.43.***.***    iburst
server 193.79.***.***    iburst
server 192.93.***.***      iburst

restrict default        noquery
restrict 127.0.0.1      nomodify noserve notrap
restrict ::1            nomodify noserve notrap

/etc/iptables:

# Allow loopback NTP queries (issued by root).
-A INPUT -i lo -p udp --dport ntp -j ACCEPT
-A OUTPUT -o lo -p udp --dport ntp -m owner --uid-owner root -j ACCEPT

# Allow public NTP queries (handled by local NTP server).
-A INPUT -i eth0 -p udp -d celestia --dport ntp -j ACCEPT
-A OUTPUT -o eth0 -p udp --dport ntp -m owner --uid-owner ntp -j ACCEPT

/etc/ip6tables:````

Allow loopback NTP queries (issued by root).

-A INPUT -i lo -p udp --dport ntp -j ACCEPT
-A OUTPUT -o lo -p udp --dport ntp -m owner --uid-owner root -j ACCEPT

Allow public NTP queries (handled by local NTP server).

-A INPUT -i 6to4 -p udp -d celestia --dport ntp -j ACCEPT
-A OUTPUT -o 6to4 -p udp --dport ntp -m owner --uid-owner ntp -j ACCEPT
````

I used to use openntpd but, for reasons I have since forgotten, I switched to chrony, and haven't looked back since then.