[tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
grarpamp
grarpamp at gmail.com
Thu Feb 20 10:43:31 UTC 2014
>> - 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.
More information about the tor-relays
mailing list