Re: starting chronyd -q unreliable

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 

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: 

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...  

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? 

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 

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]