Description of problem: Since ntpsec is compiled without any refclocks, including SHM, it can't be fed by gpsd or ntp-refclock. It also doesn't print any messages to indicate that refclock support is disabled. Version-Release number of selected component (if applicable): 1.2.0-6.fc34 How reproducible: Continual Steps to Reproduce: 1. Attach a GPS unit to the system. 2. Start gpsd with a path to the device. 3. Add "refclock shm unit 0 refid GPS" to /etc/ntp.conf 4. Start ntpd -d 5. Run ntpq -p Actual results: No error messages concerning the refclock and no peers recognized Expected results: ntpq -p shows a peer of *SHM(0) Additional info: The implications of splitting the refclocks out of ntpd was never really explained. Without refclocks, ntpd has become just a network forwarder which is a significant step down from it's former capabilities for those who need to do more than just that. Combine this with the fact that ntp-refclock only supports socket connectivity and not shared memory makes things even more difficult and complicated. I'm not even sure what the point of ntp-refclock is given that gpsd already does the same thing, plus more. Actually, I'm not sure what the point of a stripped down ntpsec is since users who just need a forwarder can use chronyd.
It wasn't intended for ntpsec to have the refclock support disabled. This was already reported in the bug #1955859 and it should be fixed in this update waiting to reach the stable threshold. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685
(In reply to Miroslav Lichvar from comment #1) > It wasn't intended for ntpsec to have the refclock support disabled. This > was already reported in the bug #1955859 and it should be fixed in this > update waiting to reach the stable threshold. > > https://bodhi.fedoraproject.org/updates/FEDORA-2021-3ffc890685 Ah, I saw that bug report but didn't associate the title "ntpsec: ntpkeygen generates weak keys" with not having refclock support. :) It also explains why I saw '--refclock=all' in the spec file in the repo but not in the spec file in the current srpm. I can test the new package and give it a vote. *** This bug has been marked as a duplicate of bug 1955859 ***