Re: starting chronyd -q unreliable

On Mon, 10 Jul 2023, Calvin Arndt wrote:

> [CAUTION: Non-UBC Email]
> 
> Thanks for reading and responding to my email Bill.
> 
> A little background.
> 
> While this server does belong to us, it was setup by a vendor and runs a very new centos knock off.
> 
> This vendors previous incarnations were all Centos 5, 6 and 7. Apparently something went BOOM in the Centos world

Apparently IBM/Redhat went BOOM and have refused to allow anyone who has not
bought Redhat to access any of the updates of the software. This sounds like
it is contrary to the GPL, but I guess that will take a while to work out in
the courts (either legal or public opinion).

> 
> and now I have a copy of "AlmaLinux release 8.6 (Sky Tiger)" I am neither impressed nor happy with it.
> 
> After about a year and a half running this server, I get this email:
> 
> [ Looks like the times are off in our POS system. 3:27 pm right now our POS system is saying 3:55 pm. Not a big deal
> but if we need to prove something it might matter. ]
> 
> That was quite surprising to me! Centos being a well written RedHat knock off, comes preconfigured with a time
> management solution. Looking around I find no time management solution installed. No biggie "yum install ntpdate"
> should about do the trick. Imagine my surprise when I find no ntpdate package available! After some googling i find
> this new kid on the block (chronyd) is available. So:

ntpdate is not a good procedure for setting clocks. It does not correct the
speed of the clock, and steps the clock. There is a flag to ntpd which allows
it to behave like ntpdate.

> 
> notmyserver:~# yum install chronyd
> 
> This is notmyserver and I'm not going to configure it for these people, so off to google to find an "update it now"
> hack for chrony... 

I am really confused why you would want to use an ntpdate like hack for the
time control, instead of using either ntpd or chrony to continuously control
the clock, and give you way way better time accuracy. It is like running a car
(gasoline) without a flywheel. It is a horribly juddery and jerky ride. 
> 
> That's how I got to where I am.
> 
> What it appears to me that you've said, is that indeed, it is a bug, in chronyd since:
> 
> "set the system clock once and exit"
> 
> which it does not do every time, is a bug. 
> 
> Not sure why you mention "detach"
> 
> Since I don't start ssh with a controlling terminal, detaching shouldn't be an issue.
> 
> But maybe there's something going on there that you have a better grasp of than I.
> 
> Anyway by now I'm sure you've figured out that I'm a debian, ubuntu etc kind of user.
> 
> About the ntpdate comments. In all my 26ish years of running linux distros, I have never once ran up against
> 
> a bug in ntpdate. It has always worked for me. Why would anyone fix what isn't broken?

Because it is broken and has been since day 1. Its control of the clock is
terrible, and, if for some reason it stops working, the clock will run off
with a bad rate and rapidly be at the wrong time.  Chrony especially, will
have trimmed the clock so that both the time (offset) and the rate are as
close as possible to UTC.

Is there some reason why you cannot run chronyd  as a daemon, which constantly
adjusts both the rate and the offset to bring the system clock into sync with
UTC?

> 
> I did go back over all my chronyd emails.
> 
> In every instance of getting the msg:
> 
> 2023-04-12T05:15:02Z Fatal error : Another chronyd may already be running
> 
> on the day prior chronyd reported that it had exited:
> 
> 2023-04-11T05:15:08Z chronyd exiting

Lichvar mentions that that bug in chony has been fixed in recent versions.


> 
> Thanks again for your time!
> 
> Calvin
> 
> 
> On 2023-07-07 12:28, Bill Unruh wrote:
>
>       No idea really but the docs say
>       -q
>       When run in this mode, chronyd will set the system clock once and exit. It will not detach from the terminal.
>
>       I would assume that if something gets in the way of setting the system clock
>       once, then it will not detach. Eg your network goes downand it cannot run the
>       burst command. But it seems to me that you are doing exactly what the chrony
>       docs say you should not do-- namely trying to use that command to control your
>       clock by running it every hour or something. It is silly and produces very suboptimal results. Someone
>       probably set up the system to use ntpdate sometime in the 90's and now
>       you are using that command to do the same thing 30 years later. Just let it
>       run as a daemon. It does not take up a lot of space nor does it take up a lot
>       of computing time.
> 
> 
>
>       William G. Unruh __| Canadian Institute for|____ Tel: +1(604)822-3273
>       Physics&Astronomy _|___ Advanced Research _|____ Fax: +1(604)822-5324
>       UBC, Vancouver,BC _|_ Program in Cosmology |____ [email protected]
>       Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/
>
>       On Fri, 7 Jul 2023, Calvin Arndt wrote:
>
>             [CAUTION: Non-UBC Email]
> 
>
>             chronyd -q should perform requested operation then exit.
>             It should never stay running.
>              
>             I start chrony daily via cron from another machine.
>             15 00 * * * ssh [email protected] "chronyd -q 'pool pool.ntp.org iburst'"
>
>             This works for a while...
> 
> 2023-06-07T05:15:01Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS
>
>             +NTS +SECHASH +IPV6 +DEBUG)
>             2023-06-07T05:15:01Z Initial frequency -12.651 ppm
>             2023-06-07T05:15:06Z System clock wrong by -0.001617 seconds (step)
>             2023-06-07T05:15:06Z chronyd exiting
>
>             Then for seemingly no reason:
> 
> 2023-07-06T05:15:01Z chronyd version 4.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS
>
>             +NTS +SECHASH +IPV6 +DEBUG)
> 2023-07-06T05:15:01Z Fatal error : Another chronyd may already be running (pid=1141), check /run/chrony/chronyd.pid
> 
>
>             So I start killing it an hour before via cron.
>             14 00 * * * ssh [email protected] "kill `pidof chronyd`|&grep -v 'usage:'"
>
>             This works fine for a month or so and then wala its back again.
>             This should never happen.
>
>             Affected machine is a centos clone distro.
>             --
>              Calvin Arndt
>             (217) 377-2979
>             [email protected]
> 
> 
>