It was moved from /var/run to /var/run/chrony.
I think it's ok to change the example systemd unit file to use
/run/chrony instead of /var/run/chrony. At least that's what I
understand systemd is complaining about.
The default path in the configure script shouldn't change, at least
for non-systemd systems.
Understood - in my humble opinion, it's a disservice to have the built-in compiled directory be different than the example unit file, as if you just compile it with the defaults but then change only the systemd unit the process hangs when trying to (re)start it, as the app is creating the PID file in a location different than where systemd is trying to look for it. Here's me changing just the unit file without the compiled-in directory:
====================
Apr 11 10:07:55 garage chronyd[6230]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6>
Apr 11 10:07:55 garage chronyd[6230]: Frequency -13.439 +/- 0.532 ppm read from /var/lib/chrony/drift
Apr 11 10:07:55 garage systemd[1]: chronyd.service: Can't open PID file /run/chronyd.pid (yet?) after start: No such file or directory
Apr 11 10:07:59 garage chronyd[6230]: Selected source 10.7.251.145
Apr 11 10:09:25 garage systemd[1]: chronyd.service: Start operation timed out. Terminating.
Apr 11 10:09:25 garage chronyd[6230]: chronyd exiting
Apr 11 10:09:25 garage systemd[1]: chronyd.service: Failed with result 'timeout'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support:
https://lists.freedesktop.org/mailman/listinfo/systemd-devel--
-- The unit chronyd.service has entered the 'failed' state with result 'timeout'.
====================
Using both the `--with-pidfile=` and changing the unit file to match is an expected result as a general user, both tasks are required - currently, the unit matches the default in ./configure, but the configure system doesn't have any hooks to process the unit file with an alternate pidfile path. (i.e. macro replacement or some standard technique via Makefile).
-te