How to set system time manually without stopping chrony #16455
-
I have an embedded server application where I am trying to use Cockpit as the "front end" UI for very basic system configuration such as setting IP addresses, reading logs, and setting the clock. This system is on an air-gapped network with no NTP servers but is running chrony acting as an NTP server to other devices on the network. The idea is the device clocks are synchronized to the clock in the server even if the server time is not synchronized to true time. Chrony serves up the local hardware clock time to the devices and that works fine. Cockpit shows the time source as "Manual" and gives the option to set the time. When I do this, it does set the local real time clock in the server but also stops chrony and does not restart it, therefore causing my NTP server function to fail and all other devices on the network to lose time source. My guess is Cockpit assumes chrony is being used as an NTP client and when you select "Manual" it wants to stop chrony and use only the hardware clock in the server. How can I get the manual time setting function in cockpit to not stop (or restart) the chrony service? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 1 reply
-
We actually don't stop/start I wonder, if keeping chronyd running is even possible, when trying to change time while ntp is being used, it fails:
I have to first turn off ntp (with Can you please show, how would you go about and do this on cmdline? |
Beta Was this translation helpful? Give feedback.
-
Thanks for the reply. Setting the time using `timedatectl set-time 'xxxx-xx-xx xx:xx:xx'` works fine with chrony running. No errors and the clock is set. NTP clients instantly get the updated time upon polling. I don't understand why setting the time manually via timedatectl should ever fail. I understand it doesn't make sense to do it if you are synchronized to an NTP server but why would it not set the clock without error then let NTP drift it back to a synchronized state?
I did some more testing and realized that selecting Set Time "Automatically Using NTP" is what is stopping chrony. Setting the clock manually via Cockpit works fine and does not stop chrony. `timedatectl set-ntp 0` does not stop chrony.
I need to revise my original question to be: Why does selecting Set Time "Automatically Using NTP" cause chrony to stop? what is the equivalent cmdline action when selecting this in the Cockpit UI? The UI time widget also reverts back to "Manual" every time I select "Automatically Using NTP".
It seems more logical that there would be a simple "set time" function in Cockpit that is not tied to NTP server or client status since there are so many ways you can configure NTP services on a linux system. Then, optionally, another widget to configure NTP server and/or client status.
As is, I can use the set time and timezone function in Cockpit to set the local clock and chrony keeps running. Is there a way to disable the other two options besides "Manual" in the set time UI widget? If I could do this I could keep users from breaking my NTP configuration. Otherwise I'll look into automatically restarting chrony if stopped.
|
Beta Was this translation helpful? Give feedback.
-
That's actually by design in timedated/timesyncd. Usually you have to make up your mind whether you want the admin or NTP to set the time, otherwise it's not well-defined what should actually happen. I just tested this in CentOS 8, which has no timesyncd, and only chronyd (enabled by default):
OOI, what OS/distro are you using? This is really not supposed to succeed.. |
Beta Was this translation helpful? Give feedback.
That's actually by design in timedated/timesyncd. Usually you have to make up your mind whether you want the admin or NTP to set the time, otherwise it's not well-defined what should actually happen.
I just tested this in CentOS 8, which has no timesyncd, and only chronyd (enabled by default):