[ntp:questions] ntpd starts despite having an invalid configuration

Sam Kottler sam at digitalocean.com
Tue Sep 30 02:24:18 UTC 2014


Greetings,

Today I ran into a rather strange behavior in ntpd on Ubuntu 14.04 (ntpd
4.2.6p3 at 1.2290-o Tue Jun  5 20:12:08 UTC 2012 (1)). There was a
configuration which was invalid deployed to systems and ntpd still started
up and properly listened on port 123 (some rows removed):

COMMAND  PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
ntpd    1554  ntp   16u  IPv4      495      0t0  UDP *:ntp
ntpd    1554  ntp   17u  IPv6      496      0t0  UDP *:ntp
ntpd    1554  ntp   20u  IPv4      504      0t0  UDP 10.30.0.2:ntp
ntpd    1554  ntp   21u  IPv6      505      0t0  UDP ip6-localhost:ntp
ntpd    1554  ntp   25u  IPv4    16089      0t0  UDP 192.168.122.1:ntp
ntpd    1554  ntp   26u  IPv4 76370284      0t0  UDP 172.30.1.1:ntp

The expected behavior is that the daemon would not properly start up, but
it seems this is ignored.

Instead, the daemon starts (this is ntpd -d -q), printing that its
configuration is invalid and hangs forever:

ntpd 4.2.6p3 at 1.2290-o Tue Jun  5 20:12:08 UTC 2012 (1)
30 Sep 04:21:17 ntpd[21902]: proto: precision = 0.559 usec
event at 0 0.0.0.0 c01d 0d kern kernel time sync enabled
30 Sep 04:21:17 ntpd[21902]: line 56 column 27 syntax error, unexpected
T_String, expecting T_EOC
30 Sep 04:21:17 ntpd[21902]: syntax error in /etc/ntp.conf line 56, column
27
Finished Parsing!!
30 Sep 04:21:17 ntpd[21902]: ntp_io: estimated max descriptors: 1024,
initial socket boundary: 16
30 Sep 04:21:17 ntpd[21902]: Listen normally on 0 v4wildcard 0.0.0.0 UDP 123
30 Sep 04:21:17 ntpd[21902]: Listen normally on 1 v6wildcard :: UDP 123
30 Sep 04:21:17 ntpd[21902]: Listen normally on 2 lo 127.0.0.1 UDP 123
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00003000 flags
00000001
30 Sep 04:21:17 ntpd[21902]: Listen normally on 3 lo ::1 UDP 123
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags
00003000 flags 00000001
30 Sep 04:21:17 ntpd[21902]: peers refreshed
30 Sep 04:21:17 ntpd[21902]: Listening on routing socket on fd #20 for
interface updates
restrict: op 1 addr 0.0.0.0 mask 0.0.0.0 mflags 00000000 flags 000005d0
restrict: op 1 addr :: mask :: mflags 00000000 flags 000005d0
restrict: op 1 addr 127.0.0.1 mask 255.255.255.255 mflags 00000000 flags
00000000
restrict: op 1 addr ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff mflags
00000000 flags 00000000
key_expire: at 0 associd 14560
peer_clear: at 0 next 1 associd 14560 refid INIT
event at 0 74.207.242.71 8011 81 mobilize assoc 14560
newpeer: <null>->74.207.242.71 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl
0 key 00000000
key_expire: at 0 associd 14561
peer_clear: at 0 next 2 associd 14561 refid INIT
event at 0 216.93.242.12 8011 81 mobilize assoc 14561
newpeer: <null>->216.93.242.12 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl
0 key 00000000
key_expire: at 0 associd 14562
peer_clear: at 0 next 3 associd 14562 refid INIT
event at 0 204.9.54.119 8011 81 mobilize assoc 14562
newpeer: <null>->204.9.54.119 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl 0
key 00000000
key_expire: at 0 associd 14563
peer_clear: at 0 next 4 associd 14563 refid INIT
event at 0 50.22.155.163 8011 81 mobilize assoc 14563
newpeer: <null>->50.22.155.163 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl
0 key 00000000
key_expire: at 0 associd 14564
peer_clear: at 0 next 5 associd 14564 refid INIT
event at 0 91.189.89.199 8011 81 mobilize assoc 14564
newpeer: <null>->91.189.89.199 mode 3 vers 4 poll 6 10 flags 0x101 0x1 ttl
0 key 00000000
event at 0 0.0.0.0 c016 06 restart
event at 0 0.0.0.0 c012 02 freq_set kernel 16.510 PPM
auth_agekeys: at 1 keys 1 expired 0

Is this the expected behavior or should I submit a patch? We've already got
one in place to prevent this happening on our systems and I'm happy to pass
it along.

Thanks!

-s


More information about the questions mailing list