How to get Chrony dead right

Server operators
1

Did anybody see this?

afbeelding
afbeelding1177Ă—622 47 KB

Why did it get so stable? I do not know if others tried this.

But I found that timedatectl was making a mess of things.

This caused it:

systemctl disable --now systemd-timesyncd

then

systemctl enable --now chrony

Then run this

root@server:/# timedatectl 
               Local time: wo 2026-02-11 18:05:16 CET
           Universal time: wo 2026-02-11 17:05:16 UTC
                 RTC time: wo 2026-02-11 17:05:16
                Time zone: Europe/Brussels (CET, +0100)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

It seems Chrony and timedatectl (systemd) are fighting between them.
Once I told Chrony is in charge the offset went flat.

See how bad this stupid this is…

afbeelding
afbeelding1177Ă—636 25.6 KB

Did anybody see this before? Why is systemd fighting Chrony? Why does a Chrony install doesn’t alter systemd?

My Strantum1 went flat…only after I altered systemd for timekeeping.

2

It is systemd-timesyncd and chronyd running together made the mess. Neither would do the mess if running alone.

1 Like
3

Sorry, i am running chrony on FreeBSD. No systemd-timesyncd for me.

1 Like
4

On Debian it is not possible to install two different NTP daemons without doing it outside the packaging system.

$ apt show systemd-timesyncd chrony | grep -E '(^Package|time-daemon)'
Package: systemd-timesyncd
Provides: time-daemon
Conflicts: systemd (<< 256.2-2~), time-daemon
Replaces: time-daemon
Package: chrony
Provides: time-daemon
Conflicts: time-daemon
Replaces: time-daemon

If your distribution’s packaging system does not ensure this, maybe it is worth a bug report. If you did it yourself from source… perhaps don’t do that!

5

I find this too restrictive. Installing a package or activating a service from a package are two different things. I can easily imagine a scenario, when you want multiple time provider packages being installed, but run the daemon only from one package. If the system is systemd based, it is not the package manager, rather the systemd should complain about the conflict, if multiple time provider services are configured to run. Or safer, straight not allowing both to run.

6

This restriction is desirable to facilitate automation in scale. Yet, I agree, this restriction could be optional.

7

I wish systemd (timedatectl) would check if another NTP is running before taking control itself.

Same problem here:

Last login: Wed Feb 11 18:03:36 2026 from 192.168.1.102
root@server:~# apt show systemd-timesyncd chrony | grep -E '(^Package|time-daemon)'

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

Package: systemd-timesyncd
Provides: time-daemon
Conflicts: systemd (<< 256.2-2~), time-daemon
Replaces: time-daemon
Package: chrony
Provides: time-daemon
Conflicts: time-daemon
Replaces: time-daemon
root@server:~#

However, I could have installed it too from source in the past, this OS has been installed and upgraded over the years, probably 20 years or so, without ever being formatted.

I could easily have messed up things, but I do not understand that during update change from SystemV (I think it’s called that) to Systemd they didn’t check.

I do not know what Debian started on this machine, but could be 6 or so, really don’t know.
Never needed to worry.

I find it silly they do not ask you about your timeserver OR the one you want to use. Should be a part of the package-select during initial install, or offer it again during dist-upgrades.

Ubuntu is even worse, they don’t even bother to inform you, they simply (re-)move to what they seem fit.