Bugzilla Bug 59653

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 ***