Re: [chrony-users] starting chronyd -q unreliable |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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 |____ unruh@xxxxxxxxxxxxxx
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 root@192.168.2.111 "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 root@192.168.2.111 "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
carndt@xxxxxxxxxxxxxxxxxx