There was something recently in the IT news about a problem with NTP servers, someone hacked the master server or something like that. NTP works a bit like DNS, so if the root server has a problem all the others follow.
Not sure if this was your problem, but the solution was something like (perhaps) choose a different NTP server and (definitely) restart NTP - does this help?
Might need to explicitly run it from the command line once to get it to sync if it's really out, using a "don't worry what diff" flag setting. Apologies for the vagueness, bit late for me to look it up properly :-D
Mike. On 27/11/12 23:02, Russell Coker wrote:
# ntpq
ntpq> lpeer
remote refid st t when poll reach delay offset jitter
==============================================================================
foo 98.143.152.5 3 - 83d 1024 0 47.125 4.906 0.000
10.1.2.3 116.66.160.39 3 - 83d 1024 0 50.747 -2.829 0.000
resolv.internod 210.9.192.50 2 - 83d 1024 0 29.030 -3.233 0.000
The NTP server in my home stopped working, the above is what I saw when I
queried it. Why would this happen?
I don't think it was non-functional for 83 days, but then I don't generally
check it that often and the system had 98 days of uptime.
I've just rebooted it (so debugging the process state won't be possible).
There was a new kernel to install.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
