With either of the above switches setup properly in /etc/sysconfig/ntpd, the daemon will eventually forget what it was told and start listening on other interfaces and/or aliases. Could this be at the default -U 5 minute timer interval?
An additional symptom is that /var/log/messages fills with periodic (5 minute interval) chatter about "Deleting interface ..." and "Listening on interface ..." nonsense. Oh...and also, these are all 802.1Q interfaces. HTH
Is ntpd really answering on other interfaces or aliases? I couldn't reproduce that. When ntpd is started on console with -n -D 4, it correctly outputs "ignore on (10) fd=23 from a.b.c.d". The problem with spamming syslog on every interface update needs to be fixed though.
Yes, in my test case with "-I eth0.1", it starts out fine...listening only on that interface. But then in exactly 5 minutes, it starts listening on all. It logs that change showing all the other interfaces enabled. And does so every 5 minutes ad nauseum.
By listening you mean a socket listed in netstat output? The manpage should have a better description. ntpd binds to all interfaces, even when -I is specified. The option actually sets interface on which ntpd shouldn't ignore packets. This prevents from another ntp daemon running and tampering with system clock. First 5 minutes when ntpd doesn't have sockets on all interfaces is a bug.
Yes, netstat, but more specifically... Upon first starting with -I eth0.8 it is indeed bound to that interface's addr. Plus an entry for lo and the 0.0.0.0:123 blocker to prevent mischief. # netstat -nulp |grep /ntpd |tr -s ' ' udp 0 0 10.0.8.1:123 0.0.0.0:* 11037/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 11037/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 11037/ntpd Seems sane enough. Then in 5 minutes, after the first click of the -U update interval, it totally changes to include specific bindings for all the other interfaces. # netstat -nulp |grep /ntpd |tr -s ' ' udp 0 0 10.0.254.1:123 0.0.0.0:* 11037/ntpd udp 0 0 10.0.253.1:123 0.0.0.0:* 11037/ntpd udp 0 0 10.0.252.1:123 0.0.0.0:* 11037/ntpd ... much more extra clutter here ... udp 0 0 10.0.8.1:123 0.0.0.0:* 11037/ntpd udp 0 0 127.0.0.1:123 0.0.0.0:* 11037/ntpd udp 0 0 0.0.0.0:123 0.0.0.0:* 11037/ntpd In this case host, there are *only* 802.1Q interfaces...and quite a few. So it's just plain messy. And I just noticed that ntpd doesn't even work with -I configured! All time servers are stuck in .INIT. indefinitely.
Maybe it's messy, but that's how ntpd is designed. The first 5 minutes is a bug and it's fixed by the same patch as the syslog spamming bug. Can you provide more info about the problem with .INIT. state? Also note that only the last -I option is used when more -I are specified on the command line. Will be fixed in next release too.
Yes, I saw the bug with multiple -I options too. Thanks! After running a single -I eth0.8 option for an hour: ntpq> peer remote refid st t when poll reach delay offset jitter ============================================================================== go.through.ru .INIT. 16 - - 128 0 0.000 0.000 0.000 tilia.zsx.hu .INIT. 16 - - 128 0 0.000 0.000 0.000 a1.develooper.c .INIT. 16 - - 128 0 0.000 0.000 0.000 *LOCAL(0) .LOCL. 10 l 46 64 377 0.000 0.000 0.001 ntpq> readvar assID=0 status=0544 leap_none, sync_local_proto, 4 events, event_peer/strat_chg, version="ntpd 4.2.4p0 Wed Mar 7 18:52:44 UTC 2007 (1)", processor="i686", system="Linux/2.6.20-1.2948.fc6", leap=00, stratum=11, precision=-20, rootdelay=0.000, rootdispersion=11.641, peer=53903, refid=LOCAL(0), reftime=c9fc42bd.2a317b4f Mon, May 21 2007 9:09:33.164, poll=10, clock=c9fc42ed.f4eeea40 Mon, May 21 2007 9:10:21.956, state=4, offset=0.000, frequency=-60.260, jitter=0.001, noise=0.001, stability=0.000, tai=0 Is there anything else I should debug? The syslogs show only the usual 5-minute interface spam. I really do suspect local config issue. Are you able to test/verify a vlan-interfaces-only setup?
ATM I can't. But I'm not sure it's related to the problem. Does it work without -I option? Does ntpdate with a public server work? If yes, please start ntpd from command line with -I eth0.8 -n -D 4, wait for few minutes and attach the output here.
Yes it works fine without -I. And ntpdate works fine too. And aha! Debugging the daemon in a console yields a couple interesting clues: Found no interface for address 209.151.236.226 - returning wildcard newpeer: local interface currently not bound newpeer: <null>->209.151.236.226 mode 3 vers 4 poll 6 10 flags 0x8001 0x1 ttl 0 key 00000000 In this case, the default route is required to access the *.pool.ntp.org servers. But ntpd isn't listening on that interface. I guess it cannot therefore pick a source address for the client queries? If it's any consolation, this host has net.ipv4.icmp_errors_use_inbound_ifaddr=1 and it's where I caught this kernel bug: http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commit;h=d8cf27287ac7fb5cbfcc4139917a997c39d841ca A different protocol, but curious/similar connundrum setting source address when multi-homed. Maybe this isn't really a bug, but an RFE that should swim upstream?
Ok, that's not a bug. The limitation is also used for outgoing packets and that's a protocol requirement according to the following comment in upstream bugzilla: https://ntp.isc.org/bugs/show_bug.cgi?id=830#c5
ntp-4.2.4p2-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
ntp-4.2.4p2-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.