On several systems that are kept up to date using emerge sync and emerge -u world, ntpd seems to have stopped working properly, i.e. it does keep time any more. This is also reflected in the following output, note the poll time still being 64 (after days of operation) and the delay etc. parts that are zero. ntpdc> peers remote local st poll reach delay offset disp ======================================================================= =ntp1.ptb.de 10.10.10.10 16 64 0 0.00000 0.000000 0.00000 =ntp2.ptb.de 10.10.10.10 16 64 0 0.00000 0.000000 0.00000 But on Debian woody systems that are using the exact same configuration and are working in the same network and filtering environment, ntpd works as normal: ntpdc> peers remote local st poll reach delay offset disp ======================================================================= =ntp1.ptb.de 10.10.10.11 1 1024 377 0.01918 -0.001616 0.01485 *ntp2.ptb.de 10.10.10.12 1 1024 377 0.01883 -0.001834 0.01483 Here's the config: restrict default noquery notrust nomodify restrict 127.0.0.1 server ntp1.ptb.de server ntp2.ptb.de logfile /var/log/ntpd.log driftfile /var/lib/ntp/ntp.drift The Gentoo Systems that have these problems were running ntpd just fine after I installed it there some time back, the configuration and the networking environment did not change. The problem as such is probably not much older than a month, I think, but I didn't keep track exactly Looks like a major bug, as ntpd becomes useless, or am I mistaken? Regards, Thomas
remove 'notrust' and try again
Ah yes, tried that, and it works now. Thanks! Maybe I should have read the documentation a bit more thoroughly, sorry about that. Still, this setup used to work with ntp-4.1.2, where the docs seem to say that the "notrust" option had the same meaning as in 4.2.0. Oh well....
yeah, seems the notrust option requires more setup on the end of users with 4.2.0 ... either way, it's behavior that has changed in ntp, not the ebuild :) *** This bug has been marked as a duplicate of 41827 ***
