- configure tor to syslog
added
'Log syslog'
- send an ntpdate -q pool to syslog every 5min,
remove when solved.
Do you mean disable ntpd daemon, and run this instead? Sounds easy enough, I imagine: service ntp stop; while true; do ntpd -gqn -l /var/log/syslog; sleep 5m; done service ntp start
I meant remove it when solved so you don't forget and you're banging on the pool every 5 for eternity.
-l /var/log/syslog - this is potentially overwriting or blocking this file which is managed by syslogd in syslog.conf, pick another new file, or just better to use ntp.conf logconfig option.
if you were running ntpd during problems, and ntpd was not working right, then ntpdate would be just a tool to separately query and print external pool time without impact to running system, for comparing with system time.
Something like -L seems to be needed but -L doesn't stop, the following - I don't know what these sorts of lines are (reading docs now, but it might take a while to figure it out) - ie I don't know why ntpd listens on LAN: 20 Feb 18:31:26 ntpd[22655]: Listen normally on 3 eth1 192.168.5.2 UDP 123
ntpd is server and client. ntp.conf can disable/restrict server and other forms of listening to just 127.0.0.1/::1, or firewall it.
BTW, looks like ntpd has the same options as ntpdate, intended for the same functions (at least on Debian, says ntpdate is deprecated).
It's said that for ages.
Now, here's the last short while of this ntpd script output: ntpd: time slew -0.015558s ntpd: time slew +0.062676s ntpd: time set +0.191404s ntpd: time set +0.187068s ntpd: time slew -0.029898s ntpd: time slew +0.027801s
If ntpd daemon was running right you'd see ntpdate -q's of under 1ms. .2sec/5min is way out so ntpd isn't running or running right.
ntpd disciplines kernel clock by calculating drift from the net and feeds back small rate deltas to kernel. no ntpd -> no discipline -> lots of drift... then these manual slews and jumpsets happen for people setting time manually, which is non ideal, get the daemon running right on its own. Tor said 100sec forward, so it maybe sees what look like the forward jumps above as accumulated. ntpd would not do that if running right, so check for some ntp thing in crontab maybe making your jump.
So it seems that the slew is somehow not being set properly, or rather, now that ntpd is being run every 5 minutes, it gets to add about .2 of a second pretty regularly (I'll continue to watch of course), so something definitely seems amiss. I'm not loading the system default ntpd config file.
It looks like time could be running slow and being _not_ updated, except a few times a day, resulting in the 2-3minute jump.
Maybe ntpd is not working/running and cron is maybe doing manual sets.
- send *.* to /var/log/all
intended to be a torrc config? It sounds like a good idea to send everything to one log file for a while, till I debug this.
man syslog.conf
interesting repeating lines all over daemon.log re ntpd (but not nothing similar in today's daemon.log though.
ntp automatically chooses who it thinks is best to listen to among given peers.
(downloading debian boot cd for example) - and no ntp server connection failures I could spot in the logs just before.
your ntp cli query may not be the same as the ntp daemon query re: udp/tcp port they use, stateful firewall timeout, etc... ie: somehow ntp blocked. Or stale/unwriteable startup drift files on disk.
I am running the 5-minutely script at the moment. But perhaps I should keep running the system ntpd at the same time, so I can do this suggested test?
I think ntpd will complain about unreachability anyway, and it seems to be doing peer picking above ok.
If [system ntp]date is set, then under ntpd running for 15min+, if ntpq -np does not show one asterisk(*) in front
Only one of ntpd or ntpdate should be doing the actual timing. For most people that means 'ntpd -g' starting as daemon at boot, with 'ntpdate -q' and 'ntpq -np' as just cli checks.