3

I recently moved my main time-server to another system, e.g. old.fqdn to new.fqdn. All subordinate ntpd daemons use ntp.fqdn as server, which is a CNAME now pointing to new.fqdn, i.e. host ntp.fqdn on that system yields:

ntp.fqdn is an alias for new.fqdn.
new.fqdn has address xxx.xxx.xxx.xxx

However ntpq -p yields:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
    old.fqdn     .INIT.          16 u    - 1024    0    0.000    0.000   0.000

which is consistent, since old.fqdn has been shut down. But why does it stick to that server? This is /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
server ntp.fqdn iburst
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1

And of course ntpd has been restarted after the DNS change. Also ntpdate -s ntp.fqdn is able to synchronize, and other systems on the network using the exact same configuration work perfectly. The only apparent difference is that those systems never used old.fqdn before. Is there any other place, where ntpd keeps record of its parental server?

System is current Debian Jessie: ntp 1:4.2.6.p5+dfsg-7+deb8u2, amd64

Update: I began to re-install ntp (apt-get --purge remove ntp && apt-get install ntp) on the workstations. After re-installation the same configuration works as expected.

Solution: The reason is that ntpd is not started with /etc/ntp.conf, but with /var/lib/ntp/ntp.conf.dhcp. The latter had the IP of old.fqdn hardcoded. Yes, in the past the systems have been configured by DHCP, currently they aren't.

The Debian start script /etc/init.d/ntp checks whether the file exists, and uses it for configuration instead. So the solution to the problem is to delete /var/lib/ntp/ntp.conf.dhcp. Don't know why I didn't check ps aux earlier.

Lars Hanke
  • 285
  • 3
  • 16
  • I think you forget to change reverse DNS zone (PTR records). – Mikhail Khirgiy Mar 07 '17 at 17:48
  • There was nothing to change. old.fqdn has an IP distinct from new.fqdn. The reverse PTR are fine for both. ntp.fqdn as a CNAME has no reverse entry. – Lars Hanke Mar 07 '17 at 17:55
  • Is showed `ntpd.conf` from ntp.fqdn server? – Mikhail Khirgiy Mar 07 '17 at 18:06
  • No these are the workstations. ntp.fqdn aka new.fqdn isn't that much different, but of course has external server entries.. – Lars Hanke Mar 07 '17 at 23:56
  • OK. Then check PTR record by command `host ip-address-of-ntp.fqdn` on workstation. – Mikhail Khirgiy Mar 08 '17 at 04:29
  • root@foo:~# host ntp.fqdn ntp.fqdn is an alias for new.fqdn. new.fqdn has address 172.16.xxx.xxx root@foo:~# host 172.16.xxx.xxx xxx.xxx.16.172.in-addr.arpa domain name pointer new.fqdn. – Lars Hanke Mar 08 '17 at 18:34
  • Please don't edit the solution into the question. If one of the given answers holds the solution, accept it, otherwise post your solution as an answer. It is perfectly acceptable to answer your own questions and accept those answers. – Gerald Schneider Mar 12 '17 at 18:08

2 Answers2

1

NTP doesn't automatically retry DNS lookups when using the server directive. Switch server to pool and restart NTP to get this behaviour.

Paul Gear
  • 4,367
  • 19
  • 38
  • Did that, restarted ntpd, but it still sticks to old.fqdn. – Lars Hanke Mar 08 '17 at 07:07
  • Seems from the edits above like the restart didn't work, and the reinstall had the effect of restarting. Check syslog for messages from ntpd and you'll probably find that it didn't restart when you thought it did. – Paul Gear Mar 09 '17 at 12:29
  • At least the ports were deallocated. Otherwise ntpdate had not worked. Syslog has start and stop messages from ntpd with different PID. – Lars Hanke Mar 10 '17 at 16:03
  • Well, glad you got it fixed, but seems we're none the wiser about the real cause... :-) – Paul Gear Mar 11 '17 at 05:57
  • Didn't fix it apart from re-installation. Saved one system for further investigation to learn something about ntpd. – Lars Hanke Mar 12 '17 at 00:18
1

I think, ntpd return the first PTR record as server name and it is old.fqdn. If you'll delete this record you'll get the second PTR record new.fqdn for same ip address of the time server. Ntpd works with ip addresses, it resolves domain names to ip at start.

You can see this ip address by command on workstation:

ntpq -p -n localhost
Mikhail Khirgiy
  • 2,073
  • 11
  • 7
  • old.fqdn and new.fqdn have different IP addresses. I don't have multiple A records for ntp.fqdn. ntp.fqdn is a CNAME, i.e. ntp.fqdn has no reverse at all and new.fqdn doesn't share anything with old.fqdn. – Lars Hanke Mar 10 '17 at 07:46
  • Do you see ip address of `old.fqdn` by command on workstation: `ntpq -p -n localhost`? – Mikhail Khirgiy Mar 10 '17 at 15:51
  • Yes, this at least is consistent. – Lars Hanke Mar 10 '17 at 16:01
  • Then you need to check ntpd logs. – Mikhail Khirgiy Mar 10 '17 at 16:07
  • There's nothing spectacular in the logs: protocol precision, interfaces to listen to, "peers refreshed", and "listening on routing socket ...". No notion where the old IP comes from. And there doesn't seem to be any config option to make logging more verbose. – Lars Hanke Mar 12 '17 at 00:27
  • Did you see in the logs that NTPD read its configuration from `/etc/ntp.conf` file? Does command `host ntpd.fqdn` (on workstation) return new ip address of new NTP server? – Mikhail Khirgiy Mar 12 '17 at 04:38
  • The logs don't show, which configuration is read, but ps did - and that was the solution to this riddle ... Thanks! – Lars Hanke Mar 12 '17 at 18:00