[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