Hi Vincent, I just deployed a new host on ci.debian.net and the chrony-wait service is failing. I noticed that the chrony-wait.service has this: """ ExecStart=/usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 """ If I run that manually I get this: debian@ci-worker-ppc64el-01:~$ sudo /usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 506 Cannot talk to daemon 506 Cannot talk to daemon This works: debian@ci-worker-ppc64el-01:~sudo /usr/bin/chronyc -h /run/chrony/chronyd.sock,127.0.0.1,::1 waitsync 0 0.1 0.0 1 try: 1, refid: 871012E4, correction: 0.000328400, skew: 0.090 Paul
Hi Vincent, But the service file has "Dynamic-user=yes", the socket can only be reached as root or _chrony. So I replaced Dynamic-user with "User=_chrony". (Maybe that's not the right solution, I leave that to you). Paul
Hello Paul, Le 2026-05-06 11:33, Paul Gevers a écrit : Any interesting logs? Assuming you are not trying to access chronyd remotely and/or that your firewall does not block UDP port 323, this typically means that chronyd is not running. If that command has been run shortly after the previous one, I assume chronyd finished starting‽ By the way, the above commands can be run without elevated privileges. Cheers, Vincent
Hello Paul, Le 2026-05-06 11:33, Paul Gevers a écrit : Any interesting logs? Assuming you are not trying to access chronyd remotely and/or that your firewall does not block UDP port 323, this typically means that chronyd is not running. If that command has been run shortly after the previous one, I assume chronyd finished starting‽ By the way, the above commands can be run without elevated privileges. Cheers, Vincent
o/, Le 2026-05-06 11:43, Paul Gevers a écrit : In this case that should not be necessary because chronyc should ping 127.0.0.1 (then ::1) if for whatever reasons the socket is inaccessible. Cheers, Vincent
Hi Vincent, Note, this is a ppc64el host. I reverted my changed, rebooted and after reboot I have this: debian@ci-worker-ppc64el-01:~$ sudo journalctl -b -t chronyd May 07 19:59:08 ci-worker-ppc64el-01 chronyd[1107]: chronyd version 4.6.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +S> May 07 19:59:08 ci-worker-ppc64el-01 chronyd[1107]: Loaded 0 symmetric keys May 07 19:59:08 ci-worker-ppc64el-01 chronyd[1107]: Using leap second list /usr/share/zoneinfo/leap-seconds.list May 07 19:59:08 ci-worker-ppc64el-01 chronyd[1107]: Frequency 0.344 +/- 0.006 ppm read from /var/lib/chrony/chrony.drift May 07 19:59:08 ci-worker-ppc64el-01 chronyd[1107]: Loaded seccomp filter (level 1) May 07 19:59:13 ci-worker-ppc64el-01 chronyd[1107]: Selected source 149.248.12.167 (2.debian.pool.ntp.org) May 07 19:59:13 ci-worker-ppc64el-01 chronyd[1107]: System clock TAI offset set to 37 seconds And here you can see it's not a timing issue: debian@ci-worker-ppc64el-01:~$ /usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 506 Cannot talk to daemon 506 Cannot talk to daemon ^C debian@ci-worker-ppc64el-01:~$ /usr/bin/chronyc waitsync 0 0.1 0.0 1 506 Cannot talk to daemon 506 Cannot talk to daemon 506 Cannot talk to daemon ^C debian@ci-worker-ppc64el-01:~sudo /usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 506 Cannot talk to daemon 506 Cannot talk to daemon 506 Cannot talk to daemon ^C debian@ci-worker-ppc64el-01:~$ sudo /usr/bin/chronyc waitsync 0 0.1 0.0 1 try: 1, refid: 95F80CA7, correction: 0.000190875, skew: 0.006 debian@ci-worker-ppc64el-01:~$ sudo /usr/bin/chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1 506 Cannot talk to daemon 506 Cannot talk to daemon I doubt it, because when I run it with sudo and no -h option it works, while it fails with -h options or without sudo. Well, after success, the next try with -h option fails again. Not for me, as shown above. Paul
Hi Paul,
Le 2026-05-07 22:06, Paul Gevers a écrit :
$ hostnamectl
Static hostname: (unset)
Transient hostname: localhost
Icon name: computer-vm
Chassis: vm 🖴
Machine ID: 3a3f50f20fae403cbb55e1948876c18c
Boot ID: 727d4364184b4aa2b468f5a1b5f52577
Virtualization: qemu
Operating System: Debian GNU/Linux 13 (trixie)
Kernel: Linux 6.12.86+deb13-powerpc64le
Architecture: ppc64-le
I'm still unable to reproduce the reported issue though. Could you please test
the attached chrony package with debugging support enabled?
Looks fine!
$ chronyc -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1
Resolved 127.0.0.1 to 127.0.0.1
Resolved ::1 to ::1
Opened UDPv4 socket fd=3 remote=127.0.0.1:323
Sent data fd=3 len=104
Timeout 1.000000 seconds
Received data fd=3 len=104
Reply cmd=33 reply=5 stat=0
try: 1, refid: C12A3F17, correction: 0.000197022, skew: 2.166
$ chronyc waitsync 0 0.1 0.0 1
Resolved 127.0.0.1 to 127.0.0.1
Resolved ::1 to ::1
Could not remove /run/chrony/chronyc.934.sock : Permission denied
Could not bind Unix socket to /run/chrony/chronyc.934.sock : Permission denied
Opened UDPv4 socket fd=3 remote=127.0.0.1:323
Sent data fd=3 len=104
Timeout 1.000000 seconds
Received data fd=3 len=104
Reply cmd=33 reply=5 stat=0
try: 1, refid: C12A3F17, correction: 0.000227216, skew: 1.709
As root:
# chronyc -d -h 127.0.0.1,::1 waitsync 0 0.1 0.0 1
Resolved 127.0.0.1 to 127.0.0.1
Resolved ::1 to ::1
Opened UDPv4 socket fd=3 remote=127.0.0.1:323
Sent data fd=3 len=104
Timeout 1.000000 seconds
Received data fd=3 len=104
Reply cmd=33 reply=5 stat=0
try: 1, refid: ACE83FDB, correction: 0.000216415, skew: 2.682
# chronyc -d waitsync 0 0.1 0.0 1
Opened Unix socket fd=3 remote=/run/chrony/chronyd.sock local=/run/chrony/chronyc.900.sock
Sent data fd=3 len=104
Timeout 1.000000 seconds
Received data fd=3 len=104
Reply cmd=33 reply=5 stat=0
try: 1, refid: C12A3F17, correction: 0.000060216, skew: 4.261
Indeed, the 'waitsync' command does not fail when running as root (or as _chrony)
and without the '-h' option because the Unix domain socket can be opened.
Yes, here lies the issue. We must understand why, in your case, the UDP socket
can't be opened as an unprivilege user. Do you apply some kind of
hardening features or anything special on that host?
Have a good day,
Vincent
Le 2026-05-09 15:50, Vincent Blut a écrit : Sigh, none of the commands below use that '-d' option as they should. Sorry about that copy/paste issue.
Hi Vincent, waitsync 0 0.1 0.0 1 Resolved 127.0.0.1 to 127.0.0.1 Resolved ::1 to ::1 Opened UDPv4 socket fd=3 remote=127.0.0.1:323 Sent data fd=3 len=104 Timeout 1.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 2.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 4.000000 seconds Could not receive message fd=3 : Connection refused Opened UDPv6 socket fd=3 remote=[::1]:323 Sent data fd=3 len=104 Timeout 1.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 2.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 4.000000 seconds Could not receive message fd=3 : Connection refused 506 Cannot talk to daemon No socket to send request Opened UDPv4 socket fd=3 remote=127.0.0.1:323 Sent data fd=3 len=104 Timeout 1.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 2.000000 seconds Could not receive message fd=3 : Connection refused Sent data fd=3 len=104 Timeout 4.000000 seconds Could not receive message fd=3 : Connection refused Paul
Hey Paul, Le 2026-05-16 17:12, Paul Gevers a écrit : Please check if chronyd is listening on 323/udp: `ss -lu | grep 323` If not, it probably means that you disabled chronyc access using the 'cmdport 0' directive. Try `chronyd -p | grep cmdport` Cheers, Vincent
Hi Vincent, debian@ci-worker-ppc64el-01:~$ ss -lu | grep 323 debian@ci-worker-ppc64el-01:~$ debian@ci-worker-ppc64el-01:~$ sudo chronyd -p | grep cmdport cmdport 0 Where is this defined? I didn't do this actively. Paul
Le 2026-05-20 21:04, Paul Gevers a écrit : If this directive has not been defined in /etc/chrony/chrony.conf, it probably has been in a configuration file in /etc/chrony/conf.d/.
Hi Vincent, I found it it /etc/chrony/chrony.conf but I really wonder how it got there as I don't see it here [1]. My file has two more lines it seems: port 0 cmdport 0 I wonder if the image I deployed (provided by the sponsor) already had the chrony.conf before I provisioned it, as I for sure don't recollect adding them myself. It was supposed to be a clean install. I suppose I can just remove those two lines again? Paul [1] https://salsa.debian.org/debian/chrony/-/blob/debian/trixie/debian/chrony.conf?ref_type=heads
Le 2026-05-20 21:31, Paul Gevers a écrit : We definitely do not alter the default values of those two directives in our default chronyd configuration. You can safely remove them, yes. Thanks for your patience, Vincent