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.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/