| Re: [chrony-users] Two Issues |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Wed, 11 Mar 2015, Weary1 wrote:
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?
It should. That is just a shell script, and a shell script works by feeding
the file line by line to the shell referenced in the #! first line of the
script. So if the command works when typed into a terminal, it should work
inside the shell script.
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.
It is probably simplest, I agree. On the other hand, this means that you
really do not need that initial start of the chrony daemon, since it does
nothing.
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:
How it happened does not really matter. It happened. use the initstepslew
directive in chrony.conf to have it step the clock if it is initially too far
out.
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.
The problem probably was UTC vs local time.
Where do you live?
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
Put it in!
chronyd default to for this function, in the absence of an explicit setting
The default is not to use it. Slew always and never step.
in chrony.conf? Or is the explicit directive in chrony.conf required to
enable the "stepping" behavior at all?
Yes.
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.
It does not, but then you must feed all the commands to it at once.
There is a script chrony-helper which will run a command to chronyc, but first
read the password from the chrony password file, and set up chronyc to allow
the dangerous commands.
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.)
Over 8 hours of slew that means that chrony is slewing at almost an hour per
hour. Actually the fastest it can slew is 1 hour in 10 hours.
(100000PPM) That is the limit of adjtimex.
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.
--
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.