| Re: [chrony-users] Two Issues |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On 03/11/2015 05:21 PM, Bill Unruh wrote:
[snip]
You could also put a command into say rc.local to do the same thing. I am not
sure of the Debian startup script, and whether you can easily make
sure that chrony starts after the network has come up. Under systemd you can
put in a dependency which says taht chrony is supposed to start after the
network. But your probably do not have systemd, and how to create such a
dependency I do not know.
I have two "rc.local" files:
/etc/init.d/rc.local
/etc/rc.local
The former contains what appears to be some scripting code for doing things
like putting a "Running local boot scripts..." message on the screen; and it
explicitly points to "/etc/rc.local".
The latter looks like the place to put the "invoke-rc.d chrony restart"
command. But I've no idea of the syntax needed. Will simply inserting that
command line before the "exit 0" (which is currently the only non-commented
line in /etc/rc.local) do the trick?
Note also that you do not have to restart chrony, you could also issue
commands via chronyc to tell it to put the sources online. But restarting it
would work.
Whatever is simpler. I don't mind the restart, if that will reliably clean up
the problem.
Just such a situation occurred recently, which was possibly further
exacerbated by the fact that we just went through the Daylight Savings Time
transition. The end result is, the system clock on the server is "out" by
something like 8-1/2 hours. Yes, based on the "System Time" reports from the
How in the world did that happen? That cannot be due to any clock drift,
because at even 100PPM. that would take 10 years to accumulate.
Weeeeellll... There is one other complicating factor, which *MAY* have had a
hand in the server's System Clock getting so far out of whack, and which I
didn't mention earlier:
A week or two ago, that system spontaneously froze up, for no apparent reason.
(There *MAY* have been a small power glitch; but the system runs off a
good-size UPS with fresh batteries, and I got no indication of a "real" power
loss.). In any event, when I re-booted the system to get it back online, it
had gotten THOROUGHLY "confused" -- it lost all its CMOS/BIOS settings, even
to the point of "forgetting" what CPU was installed and what core clock rate /
multiplier / etc. it was supposed to be running at.
Unsurprisingly, the RTC was also FUBAR during this fiasco. In the course of
fixing all the BIOS settings, I reset the RTC based on my wristwatch -- which
was obviously not super-precise; but it should not have been off by more than
a minute or so.
Now, the motherboard in that system is old enough that the CMOS battery MAY be
reaching the end of its lifespan, which in turn MAY (at least partially)
explain why the system went *SO* far out to lunch. But OTOH, even through
several subsequent reboots (including some which cycled power completely off),
the problem did not recur. Still, I've made a note to get a new battery, and
install it at the next convenient opportunity; but that hasn't happened yet.
Unfortunately, with everything else that was going on at that (worst possible,
of course) moment, I did not take note of whether chrony was "happy" or not.
I did notice the problem with chrony several days later (IIRC, this was after
a manually forced reboot after a kernel update).
Look at the initstepslew directive. This tells chrony to initially step the
clock if it is too far off, and only slew it if it is off by some amount you
configure.
Based on the Chrony User Guide at <http://chrony.tuxfamily.org/manual.html>,
that is apparently supposed to be in chrony.conf. But at least on my
system(s), no such entry exists, even in "commented out" form. So what does
chronyd default to for this function, in the absence of an explicit setting in
chrony.conf? Or is the explicit directive in chrony.conf required to enable
the "stepping" behavior at all?
Problem #2:
In an effort to speed up the "recovery" process from such gross errors, I've
tried to manually issue certain chronyc commands (such as "offline",
"online", "burst"). But each time, I get only "501 Not authorized" in
response. I've tried entering the chrony password, as contained in the
chrony.keys file, but to no avail. Now part of the problem MAY be that I am
You have to make sure that a reference to the key number is in chrony.conf and
that key number has the password in the keys file.
I think I've got both of those covered. My chrony.conf includes:
keyfile /etc/chrony/chrony.keys
and:
commandkey 1
(Both of these were in the default chrony.conf, and I left them alone.)
That would just run chrony and run the password command and exit, and it would
forget that you entered the password.
chronyc
chronyc> password abcxyz
200 OK
chronyc> Other commands
...
chronyc> quit
Ah, HA!
I didn't realize that chronyc needed to be run in interactive mode in order to
use "passworded" commands. Thank you.
So with this, I *think* I can bring the server's System Clock up to "almost
correct" using the "makestep" command (then let chronyd's automatic adjustment
take over from there). But I'm also a little leery of screwing things up
worse than they already are. At last check, "chronyc tracking" was reporting
(among other things):
System time : 24732.421875000 seconds slow of NTP time
(Yes, my earlier calculations projecting nearly a week to recover were wrong.
It's now looking like about 7 hours.)
So, assuming I did it right now, would the correct "makestep" command be:
chronyc> makestep 24732
???
Or perhaps:
chronyc> makestep -24732
???
(Among other uncertainties, I'm not sure of the "polarity" here, as in the
direction of the jump vs. the system clock being fast/slow)
Thanks for your help.
--
Weary1
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.