Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision |
| timepi [2024/11/14 02:30] – created - external edit 127.0.0.1 | timepi [2025/02/01 14:06] (current) – [Verify Operation and Troubleshooting] admin |
|---|
| </code> | </code> |
| |
| If it's not, check the contents of ''/etc/chrony.conf''. Specifically, make sure that the ''refclock SOCK'' entry is correct, and make sure that GPSD is being started after chronyd. | If it's not, check the contents of ''/etc/chrony.conf''. Specifically, make sure that the ''refclock SOCK'' entry is correct, and make sure that ''gpsd'' is being started after ''chronyd''. |
| | |
| | ==''systemd'' == |
| | An easy way to check the startup order is to use the ''systemd-analyze plot >bootup.svg'' command to generate an image of the order in which ''systemd'' is starting services, and how long they take to start, drawn sequentially from top to bottom. Here's a subset of an example of such an plot on a system where ''chronyd'' isn't connecting to ''gpsd'': |
| | |
| | {{::chrony_no_gpsd.png?600|}} |
| | {{::gpsd_chrony_startup_sequence.png?600|}} |
| | |
| | Here, we can see that while ''gpsd.service'' is indeed starting after ''chronyd.service'', //''gpsd.socket''// is starting earlier. ''gpsd.socket'' is the component of ''gpsd'' that writes to the SOCK that ''chronyd'' creates - and if it's started first, it will not send data to chrony. |
| |
| == Client Test == | == Client Test == |
| |
| {{:ntp_check.png?300|}} | {{:ntp_check.png?300|}} |
| | |
| | On linux you can quickly build something I threw together called [[ntpQuery]]. |
| | |
| | {{:ntpquery2.png?400|}} |
| | |
