| Re: [chrony-users] Two Issues |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On 03/11/2015 07:16 PM, Bill Unruh wrote:
On Wed, 11 Mar 2015, Weary1 wrote:
[snip]
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.
Excellent.
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.
That's a fair point, which brings us back to simply starting chrony later in
the start-up sequence. I wish I could remember what it was I read which
pointed to the idea that "earlier is better"; but I think it had something to
do with chrony's long-term accuracy (based on its own stats, etc.).
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.
That will require a restart of chrony, after I change chrony.conf. I'll get
to that after dealing with these messages.
The problem probably was UTC vs local time. Where do you live?
East coast, USA.
I am well aware that straight Unix/Linux systems (as opposed to dual-boot
Windows/Linux systems) run the RTC on UTC; so I'm reasonably certain that I
*did* do the math (vs. my wrist watch) to set the RTC to UTC. What I'm *not*
so sure of at this point is, did I get it right? I suppose there's a chance
that I borked the conversion and went the wrong way (i.e., set the RTC to five
hours behind my wrist watch, instead of five hours ahead of it).
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!
Will do. Any suggestions for the specific parameters?
I'm kind'a surprised it isn't there by default, as one would think that
something so critical to quickly correcting for such gross errors (even if
user-induced) would be useful to all.
The default is not to use it. Slew always and never step.
I assume there's a reason for that; but no clue what it would be.
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.
Well, having confirmed that the "interactive mode" approach works, I'll stick
with that, for now.
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.)
And guess what?
Here we are, roughly 12 hours after I wrote the above, and "chronyc tracking"
is now reporting:
System time : 21013.990234375 seconds slow of NTP time
So much for "about 7 hours". <~>
(I'm becoming more confused, not less.)
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.
I'll take your word for that.
But FWIW, it looks like my server is indeed slewing at (or near) that max.
rate: Over ~12 hours (43,200 seconds), it's gotten 3,719 seconds closer to
correct. That works out to 86,088 PPM.
--
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.