Description of problem: On a clean minimal installation, using systemd-timesyncd instead of chrony causes an ordering cycle, which effectively prevents systemd-timesyncd from being started on boot. Version-Release number of selected component (if applicable): systemd-timesyncd-250.3-1.el9.x86_64 How reproducible: Always Steps to Reproduce: 1. dnf install epel-release 2. dnf install systemd-timesyncd 3. systemctl disable chronyd 4. systemctl enable systemd-timesyncd 5. systemd-analyze verify default.target Actual results: sysinit.target: Found ordering cycle on systemd-timesyncd.service/start sysinit.target: Found dependency on dbus.socket/start sysinit.target: Found dependency on sysinit.target/start sysinit.target: Job systemd-timesyncd.service/start deleted to break ordering cycle starting with sysinit.target/start Expected results: No output. Additional info: Re-enabling chronyd (in addition to systemd-timesyncd) somehow makes the cycle go away. But then I wouldn't need systemd-timesyncd anyway ...
I guess this is caused by this patch: https://src.fedoraproject.org/rpms/systemd-extras/blob/epel9/f/9000-Start-after-dbus.socket-rather-SELinux-inotify-watch.patch However this patch is unfortunately required due to bugs that Red Hat didn't fix, yet.
Do this patch actually needed in el9+ in almost year'25? Currently this breaks of systemd-timesyncd usage in EL9. I made changes, that add's network & dns before service running and ordering cycle problem resolved ``` --- systemd-timesyncd.orig 2023-05-16 03:55:49.000000000 +0700 +++ systemd-timesyncd.service 2024-11-13 20:28:53.086000000 +0700 @@ -13,8 +13,8 @@ Documentation=man:systemd-timesyncd.serv ConditionCapability=CAP_SYS_TIME ConditionVirtualization=!container DefaultDependencies=no -After=systemd-sysusers.service dbus.socket -Before=time-set.target sysinit.target shutdown.target +After=systemd-sysusers.service +Before=sysinit.target network.target nss-lookup.target time-set.target Conflicts=shutdown.target Wants=time-set.target ```