Am looking to have a small NTP server (Chrony) provide time to different computers located on the same student under water vehicle connected via ethernet cables. We are primarily concerned with having different parts of the vehicle synchronized to each other to <10ms over several days. Some electronics are being synchronized directly by a 1PPS source, so keeping the NTP server and the 1PPS source synchronized is important. "System time" synchronized to the real world is not required but nice to have if it comes for free. Currently we have: - 1PPS frequency source - imbedded computer with an RTC which is read at startup - GPS Receiver but this ideally cannot be relied on as GPS does not work well underwater. We currently feed the 1PPS signal and the GPS serial string into a USB-Serial converter (FTDI), this is then ready by gpsd, which correctly picks up the 1PPS and the GPS string for Chrony. This works and provides us about 2us synchronisation with 1PPS & GPS. The existing setup has limitations for our application: 1. gpsd requires a valid gps time string to initialize the time, this is not always available as we have poor GPS reception on the water and none, underwater. 2. gpsd also require continuous valid strings to process the 1pps interrupt. This is mainly an issue if we want to disable the GPS receiver underwater to save power but want to keep syncing to the 1PPS. 3. Once GPS is lost or the GPS unit is turned off, the system time starts drifting from the 1PPS source. I realize that "gpsd" is heavily relying on gps, so i am using the wrong tool. Questions: 1. Is it possible to feed the 1PPS directly to chrony? 1.1 Could chrony use this 1PPS and the system time alone without ever getting real world time source apart from the RTC? 2. Are they examples on how to add a /dev/pps source using an FTDI USB-to-Serial converters RI or DCD pin? e.g what gpsd does under the hood, but without using it.

I have configured the chrony NTP server on rhel8 by using the commands chronyc sources -v and chronyc tracking to verify the time synchronization and it has succeeded. However, when I use the command w32tm /monitor /computers:XX.X.XX.XXX from Win10 to verify it, it gives me the following error ICMP: 0ms delay NTP: Error ERROR_TIMEOUT-No response from server within 1000 ms. vi /etc/chrony.conf server XXX.XX.XX.220 iburst server XXX.XX.XX.219 iburst server XXX.XX.XX.218 iburst driftfile /var/lib/chrony/drift makestep 0.2 5 #rtcsync #hwtimestamp * #minsources 2 # Allow NTP client access from local network. #allow 192.168.0.0/16 allow XXX.XX.XX.0/24 #local stratum 10 #keyfile /etc/chrony.keys leapsectz right/UTC logdir /var/log/chrony log measurements statistics tracking leapsecmode slew maxslewrate 1000 smoothtime 400 0.001 leaponly bindaddress 127.0.0.1 logchange 0.5 but when I use the following command to check it,it can not get the clients information. [root@test etc]# chronyc clients Hostname NTP Drop Int IntL Last Cmd Drop Int Last =============================================================================== How can I fix this?

I have a vanilla install of CentOS 8 ad am using it as an NTP server with Chronyd. It is silently refusing to answer a host on its own network, but it *will* answer another host I have tested off network: On the left, a host on its own network. Asking it repeatedly for response and it sending nothing. On the right, a host off network that syncs without problem. I have not configured any sort of ACL nor set any settings on chronyd other than to set an upstream NTP server. I just don't have any idea why it would respond to one but not the other.

Trying to get chrony working **on a LAN**, in **RHEL-8.10**. The service on either my chrony server or a client appears to be functional as reported by a service chronyd status -l. However I cannot get time to sync between the two, they are off by a couple minutes. # this command is performed on a time client server, having ip 192.168.1.4 for example chronyc> sources -a -v .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / 'x' = may be in error, '~' = too variable, '?' = unusable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^? 192.168.1.1 3 6 377 5 -1500us[-1705us] +/- 500ms # I edited the name/ip here for posting, it resolves to the hostname via dns in our little LAN And chronyc tracking reports all zeros, versus on another server that is online [intranet] is sync's to a dedicated time server and here the time matches that from time.gov to the second, and chronyc tracking reports with things like System time : 0.000830548 seconds fast of NTP time and not all zeros. on my LAN systems, I have tried setenforce 0 and service firewalld stop and neither helped. What causes the '?' = unusable in chronyc sources ? This seems to be the most obvious problem comparing between a working setup versus non-working. I feel like my error is on my RHEL-8.10 server that I am trying to make a chrony time server that others sync to, is there anything special in that /etc/chrony.conf that is needed that isn't obviously already documented in that default file as provided by redhat? Below is my /etc/chrony.conf from the server I want to be the time server on my LAN having ip 192.168.1.1, which does not time sync to anything else. Am I missing anything below that would cause the '?' = unusable to happen when doing chronyc sources -a -v from a time client on my LAN? # Record the rate at which the system clock gains/losses time. driftfile /var/lib/chrony/drift # Allow the system clock to be stepped in the first three updates # if its offset is larger than 1 second. makestep 1.0 3 # Enable kernel synchronization of the real-time clock (RTC). rtcsync # Enable hardware timestamping on all interfaces that support it. #hwtimestamp * # Increase the minimum number of selectable sources required to adjust # the system clock. #minsources 2 # Allow NTP client access from local network. allow 192.168.1.0/24 # Serve time even if not synchronized to a time source. local stratum 10 # Specify file containing keys for NTP authentication. keyfile /etc/chrony.keys # Get TAI-UTC offset and leap seconds from the system tz database. leapsectz right/UTC # Specify directory for log files. logdir /var/log/chrony # Select which information is logged. #log measurements statistics tracking And on my clients their chrony.conf simply has server 192.168.1.1 iburst at the top.

# timedatectl reports System clock synchronized: no even when NTP service: active and # systemctl status chronyd shows active (running), and the logs therein don't show anything like an error; I see for example "Using right/UTC timezone to obtain leap second data". This is a RHEL 8 system, the /etc/chrony.conf file is the default. I expected to see System clock synchronized: yes, which I think means the system is getting synchronized with the pool specified in /etc/chrony.conf. Maybe I'm missing something misinterpreting what this means? Edit: Full # timedatectl output

Local time: Tue 2020-10-06 12:11:32 PDT
           Universal time: Tue 2020-10-06 19:11:32 UTC
                 RTC time: Tue 2020-10-06 19:11:32
                Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

Edit: Answer is in https://serverfault.com/questions/1036676/system-clock-synchronized-no-flip-it-to-yes

i hope this post finds you well, i have a three NTP servers ( two chrony , and one ntpsec ) , that peer to peer to each , the problem is when i pass to authentication ( symmetric key between ntp servers ), when i run sudo systemctl restart chronyd it always : ]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP ]: Wrong owner of /run/chrony (UID = 110) 1: Disabled command socket /run/chrony/chronyd.sock ]: Loaded 2 symmetric keys ] ]: Missing read access to /etc/chrony/chrony.keys: Permission denied Initial frequency -4.700 ppm ]: Could not open /var/log/chrony/tracking.log Permission denied ]: Loaded seccomp filter (level 1) Started chrony.service- chrony, an NTP client/server. ]: Could not open /var/log/chrony/measurements.log: Permission denied whoever i do : > sudo useradd -r -s /usr/sbin/nologin -d /var/lib/chrony -U chrony > sudo chown -R chrony:chrony /etc/chrony sudo chown -R chrony:chrony > /var/log/chrony sudo chown -R chrony:chrony /var/lib/chrony sudo chown > -R chrony:chrony /run/chrony sudo chmod -R 755 /var/log/chrony sudo chmod -R 750 /var/lib/chrony sudo chmod -R 750 /run/chrony sudo chmod > 640 /etc/chrony/chrony.keys

Time synchronization with an external NTP server in my Docker container works for a few seconds, but after that, synchronization stops working : logs : 2024-09-08T20:54:15Z chronyd version 4.0 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG) 2024-09-08T20:54:15Z Initial frequency 83333.333 ppm 2024-09-08T20:54:15Z Using right/UTC timezone to obtain leap second data *2024-09-08T20:54:20Z Selected source 196.200.160.123 (2.debian.pool.ntp.org)* 2024-09-08T20:54:20Z System clock wrong by -5318.299142 seconds 2024-09-08T19:25:41Z System clock was stepped by -5318.299142 seconds 2024-09-08T19:25:41Z System clock TAI offset set to 37 seconds 2024-09-08T20:54:45Z Forward time jump detected! **2024-09-08T20:54:45Z Can't synchronise: no selectable sources** /etc/chrony/chrony.conf file : confdir /etc/chrony/conf.d pool 2.debian.pool.ntp.org iburst sourcedir /run/chrony-dhcp sourcedir /etc/chrony/sources.d keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift ntsdumpdir /var/lib/chrony logdir /var/log/chrony maxupdateskew 100.0 rtcsync makestep 1 3 leapsectz right/UTC

it's possibile see log of sync query from client? There are tracking.log statistics.log measurements.log but in this log there are not clients query I try from my client to query with command > ntpdate -q myntpserver but nothing in logs! in my log i see: ==> /opt/chronyd/data/log/measurements.log /opt/chronyd/data/log/statistics.log /opt/chronyd/data/log/tracking.log 192.168.88.145.123: NTPv4, Client, length 48 10:20:37.143920 IP 192.168.88.145.123 > 192.168.88.141.50204: NTPv4, Server, length 48 10:21:08.456605 IP 192.168.88.140.53060 > 192.168.88.145.123: NTPv4, Client, length 48 10:21:08.457822 IP 192.168.88.145.123 > 192.168.88.140.53060: NTPv4, Server, length 48 10:21:09.176344 IP 192.168.88.141.52451 > 192.168.88.145.123: NTPv4, Client, length 48 10:21:09.177444 IP 192.168.88.145.123 > 192.168.88.141.52451: NTPv4, Server, length 48 10:21:40.488820 IP 192.168.88.140.54269 > 192.168.88.145.123: NTPv4, Client, length 48 10:21:40.490039 IP 192.168.88.145.123 > 192.168.88.140.54269: NTPv4, Server, length 48 10:21:41.208052 IP 192.168.88.141.53443 > 192.168.88.145.123: NTPv4, Client, length 48 10:21:41.209239 IP 192.168.88.145.123 > 192.168.88.141.53443: NTPv4, Server, length 48 10:22:13.522921 IP 192.168.88.140.35788 > 192.168.88.145.123: NTPv4, Client, length 48 10:22:13.524212 IP 192.168.88.145.123 > 192.168.88.140.35788: NTPv4, Server, length 48 but nothing in log! thanks in advance

Running RHEL-8.9 I have a handful+ servers in a computer lab, which do not have an internet connection and [currently] have no means of fetching any kind of stratum-0 type time. We therefore manually set time in linux to local time on one sever which is good enough, and the server bios/efi clock is set to UTC. I am having issues getting other servers to time sync, if I manually do a date on each simultaneously they are 60+ seconds off and I am getting frustrated with this not working. If anyone is so inclined can you describe in as short as possible the process [which should be simple?] to do the following? - Server @ 192.168.1.1 I have made my time server - firewalld port 123-udp and 323-udp is open - /etc/chronyd.conf - has no server line, because it does not fetch a time - has allow 192.168.1.0/24 - has local stratum 10 - Servers @ 192.168.1.x - /etc/chrony.conf has server 192.168.1.1 iburst maxpoll 10 - rest of chrony.conf is whatever is the default from a clean install from rhel-8.9-x86_64-dvd.iso; everything else basically commented out **How can I immediately time sync in linux**, on a new server having a clean install from rhel-8.9.iso where its clock is however many minutes off from my 192.168.1.1 server? So I don't care how far off the time is and I do not expect any software to break as it's a clean install with only me ssh'ing in as root at this point in time. And what is the simplest way to check that chrony is working a [client] system that it can connect to a time server and that it *will* time sync? And if my clock if off 45 seconds how do I know when it will be sync'd ? What can I look at that will give me confidence that when I check an hour later or tomorrow that the time will be sync'd, rather than coming back each day for a week finding no time sync.

I'm looking to provide precise time to a Raspberry Pi 4 without internet via a UBLOX GNSS module that sends NMEA sentences to /dev/serial0 and a pulse-per-second (PPS) signal to /dev/pps0. All this information arrives right after boot as verified with gpsmon -n and sudo ppscheck /dev/pps0. However, chrony takes many minutes to pick up the information. I have configured chrony by creating /etc/chrony/conf.d/gps.conf with the content:

refclock SHM 0 refid NMEA offset 0.1 precision 0.2 poll 0
refclock PPS /dev/pps0 refid PPS lock NMEA poll 0 trust prefer
log refclocks

I have experimented a lot with the options in the config file: delay, offset, precision, trust, noselect, prefer and lock, to no avail. I've left /etc/chrony/chrony.conf the way it always was:

# Welcome to the chrony configuration file. See chrony.conf(5) for more
# information about usable directives.

# Include configuration files found in /etc/chrony/conf.d.
confdir /etc/chrony/conf.d

# Use Debian vendor zone.
pool 2.debian.pool.ntp.org iburst

# Use time sources from DHCP.
sourcedir /run/chrony-dhcp

# Use NTP sources found in /etc/chrony/sources.d.
sourcedir /etc/chrony/sources.d

# This directive specify the location of the file containing ID/key pairs for
# NTP authentication.
keyfile /etc/chrony/chrony.keys

# This directive specify the file into which chronyd will store the rate
# information.
driftfile /var/lib/chrony/chrony.drift

# Save NTS keys and cookies.
ntsdumpdir /var/lib/chrony

# Uncomment the following line to turn logging on.
#log tracking measurements statistics

# Log files location.
logdir /var/log/chrony

# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

# This directive enables kernel synchronisation (every 11 minutes) of the
# real-time clock. Note that it can’t be used along with the 'rtcfile' directive.
rtcsync

# Step the system clock instead of slewing it if the adjustment is larger than
# one second, but only in the first three clock updates.
makestep 1 3

# Get TAI-UTC offset and leap seconds from the system tz database.
# This directive must be commented out when using time sources serving
# leap-smeared time.
leapsectz right/UTC

The issue is: after rebooting, chrony doesn't receive data from gpsd or the PPS. I've verified this by running chronyc sources (It shows hyphens for both in the LastRx column.) and sudo tail -f /var/log/chrony/refclocks.log (no updates there). After several minutes (5-20) chrony starts getting time from gpsd and PPS and updates the system time a few seconds after that (verified the same way as explained in the previous paragraph). Sometimes it's different and chrony takes several more minutes to read the PPS after getting time from gpsd. I've tried rebooting many times and the result is always the same. Data from the GNSS module comes in immediately and can be accessed with gpsmon -n and ppscheck right after boot. **Then, why does chrony need over 5 minutes to get the same information?** By the way, after resetting the system time with sudo date +%T -s "12:00:00", and sudo systemctl reastart chrony there's no issue: chrony updates the system time within seconds. One thing I've tried for troubleshooting is to run sudo ntpshmmon. It shows NTP2 and NTP3 samples right from boot but NTP0 samples only show up at the same time as chrony starts connecting to the refclocks. That should help narrow down the cause but I have no idea how to continue debugging from there. This question has been adapted from my question on the Raspberry Pi Stack Exchange .

Documentation states chrony uses port 323udp by default, versus port 123udp that old NTP used. But where is port 323 defined, because I do not see it in the default /etc/chrony.conf as it comes in a clean install of either RHEL-7.9 or RHEL 8.9. Also, in either /etc/firewalld/zones/public.xml which is the default firewall from a clean install, or even in my custom firewall xml file, I do not open either port 123 or port 323 and chrony seems to work - my time is correct the service is successfully running and chronyc tracking reports Reference ID : 1234ABCD (correctserver.com) Stratum : 4 Ref time (UTC) : Tue Jan 02 20:35:42 2024 System time : 0.000383474 seconds fast of NTP time Last offset : +0.000296875 seconds RMS offset : 0.000736834 seconds Frequency : 11.411 ppm fast Residual freq : +0.003 ppm Skew : 0.094 ppm Root delay : 0.024757780 seconds Root dispersion : 0.091295145 seconds Update interval : 1036.6 seconds Leap status : Normal A netstat -lun does shows Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 127.0.0.1:323 0.0.0.0:* udp6 0 0 ::1:323 :::* Biggest question is why is this like this regarding the firewall, since I am pretty sure I did not explicitly open port 323. Where should I look for how port 323udp gets opened with firewalld (in RHEL-7.9) ? And where does chrony explicitly have port number = 323 defined? /etc/firewalld/zones/public.xml has only this : Public For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

I paused the virtual machine on the VM and disconnected its internet connection without rebooting the system. When I started the system from sleep mode without rebooting, the system clock continued where it left off and could not show the correct time? What will I do in such a situation? - my time data for the hour **before** I paused my virtual machine (it is also real time for my host)

% chronyc sourcestats
---------------------
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   139 -46792.738  67288.219   -326ms   890ms
108.175.15.67               6   3   140 -44764.793  61909.766   -188ms   961ms
gopher.fart.website         6   3   140 -49022.652  84747.266   -217ms  1224ms
edge-iad.txryan.com         6   3   139 -45642.164  67798.562   -230ms  1032ms


% chronyc tracking
------------------
Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000000 seconds slow of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 0.769112766 seconds
Update interval : 7.0 seconds
Leap status     : Normal

% date
-----------------
Mon Dec 25 12:55:18 PM +03 2023

% hwclock
-----------------
2023-12-25 12:55:13.078474+03:00

- After disconnecting from the internet, I waited for a while and then when I opened the VM, the clock did not show the correct time. Also, when I get this output; my real host date *(Monday, December 25, 2023 1:28:58 PM)* *(in short, when I disconnected the internet connection and started the system again, it could not be started synchronously with the time of my main host.)*

% chronyc sourcestats
---------------------
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   139 -46792.738  67288.219  -5592ms   890ms
108.175.15.67               6   3   140 -44764.793  61909.766  -5226ms   961ms
gopher.fart.website         6   3   140 -49022.652  84747.266  -5734ms  1224ms
edge-iad.txryan.com         6   3   139 -45642.164  67798.562  -5367ms  1032ms

% chronyc tracking
------------------
Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000000 seconds fast of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 6.036798477 seconds
Update interval : 7.0 seconds
Leap status     : Normal

% date
-----------------
Mon Dec 25 12:57:11 PM +03 2023

% hwclock
-----------------
2023-12-25 12:57:05.629692+03:00

- After Internet Connection ---------------------------

Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std Dev
==============================================================================
131.153.171.22              6   4   343   -5616574     341926   -1958s   15.7s
108.175.15.67               6   4   343   -5631052     251508   -1960s   12.1s
gopher.fart.website         6   4   343   -5618134     301975   -1963s   14.2s
edge-iad.txryan.com         6   4   343   -5635317     275298   -1964s   13.2s

Reference ID    : 8399AB16 (131.153.171.22)
Stratum         : 3
Ref time (UTC)  : Mon Dec 25 09:55:11 2023
System time     : 0.000000001 seconds fast of NTP time
Last offset     : -5.681410313 seconds
RMS offset      : 1.796643019 seconds
Frequency       : 5.307 ppm fast
Residual freq   : -46792.738 ppm
Skew            : 8.997 ppm
Root delay      : 0.147369087 seconds
Root dispersion : 16.738962173 seconds
Update interval : 7.0 seconds
Leap status     : Normal

Mon Dec 25 01:01:00 PM +03 2023
2023-12-25 13:01:00.293480+03:00

---------- Also, How often does my system time refresh via Chrony? When the system is turned on or as long as it is connected to the internet? How can I set this?

When I study with **chronyc tracking** command I got some fields and I need more description about it.

chronyc tracking
----------------
Reference ID    : B9E84541 (nobody.yourvserver.net)
Stratum         : 3
Ref time (UTC)  : Wed Dec 20 16:15:43 2023
System time     : 0.000761215 seconds slow of NTP time
Last offset     : -0.000511070 seconds
RMS offset      : 0.001488404 seconds
Frequency       : 2.166 ppm fast
Residual freq   : -0.066 ppm
Skew            : 2.884 ppm
Root delay      : 0.041033130 seconds
Root dispersion : 0.004155959 seconds
Update interval : 517.6 seconds
Leap status     : Normal

In the example output above, can you describe and give some more details about **"Stratum** (what is the number of layers here? I'm working on a VM machine), **Skew,Root Delay and Leap"** fields (except man doc)

I am new to this business, and could not find the answers to the following: - In order for ntpd client to sync up with chronyd server using a hex key value, I found that I need to strip out the HEX: prefix from the hex keys used by chronyd before I upload this key file to my ntpd client. Is this is a known fact about this type of interworking, or a specific issue with my client? - ntpd requires full key length when using hex keys, i.e., SHA-1 has to be 40-hex symbols, SHA-256 64-hex symbols. Is this design intent of ntpd, and a known practice used by IT when generating and configuring ntpd keys? - ntpd implementation assumes (even in latest version ntp4.2.8p17) that if strlen(key) 20 characters, then it is treated as hex format. 1) Why 20 is the boundary limit to make this segregation? Gathering from RFCs, MD5 digest is 128 bits, SHA-1 digest is 160 bits, SHA256 is 256, etc. Was the 20-characters limit based on early implementation of ntpd when MD5 and SHA-1 were only on mind? 2) Is this 20-character limit known and expected by IT folks in industry, and accepted as a de-facto standard? 3) What repercussions can you think of if this limit is changed to be based on key type, i.e., if SHA-1 then limit is 20, if SHA-256 then limit is 32,... Could this cause backward compatibility issues?

I'm working on a project which will acquire a lot of timestamped data at fairly high resolution (50 samples per second) over a very long period of time (years). The solution includes various failover mechanisms. During the lifespan of this project it's reasonable to assume that some data-loggers will need to be replaced. IE some will come online once data acquisition has already stated by others. Given the nature of the data, it would be very bad if some data were recorded with inaccurate timestamps, even a handful of seconds out. NTP should be solid enough for this solution, and even if network is lost for a few hours the drift on the internal clock should be too small to cause a significant problem. *Actually we care less about data during internet outages for esoteric reasons*. **What bothers me** is what happens when a data-logger is rebooted. Or booted for the first time. I want the device to reliably stabilise its system time using NTP before it meshes into the failover solution. How can I determine the current reliability of the system time with respect to either chrony or ntpd. That is, how can I get a value from either, telling me: - how recently they last synchronised - If possible, a confidence value in the last update* By Confidence I mean something along the lines of total round trip time of the NTP packets... which is of course part of the NTP specification.

I've used systemd-timesyncd as my system timekeeper for several years now. I run a Debian *derivative* called **raspbian** for my Raspberry Pis. I'm mostly very pleased with the SNTP client that is systemd-timesyncd, but would like to experiment with chronyd for use in off-grid applications. The following command may be used to list the configuration of systemd-timesyncd:

$ systemctl cat systemd-timesyncd

In **buster**, there was a section of code in this listing that provided systemd-timesyncd with the ability to "excuse itself" if it found another timekeeping service (NTP daemon) installed:

# /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[Unit]
# don't run timesyncd if we have another NTP daemon installed
ConditionFileIsExecutable=!/usr/sbin/ntpd
ConditionFileIsExecutable=!/usr/sbin/openntpd
ConditionFileIsExecutable=!/usr/sbin/chronyd
ConditionFileIsExecutable=!/usr/sbin/VBoxService

At ***some point*** after the release of **buster** (concurrent w/ release of **bullseye**??), the above scheme was altered; the command systemctl cat systemd-timesyncd no longer contains any references to restricting or inhibiting startup of systemd-timesyncd if other timekeepers are found. Does anyone recall the history of this change? More importantly, does systemd-timesyncd still inhibit its startup if it finds another timekeeping daemon installed? Where/how is this done?

Assume there is a PC with dead CMOS battery and unreliable Internet connection. As far as I understand, both chrony and ntpd try to correct huge time differences (years) *once* – upon startup, – but then switch to slewing during normal system run, which will panic and bail out if the needed time correction is more than 1000 s. Sometimes the Internet connection is absent at boot time but comes up later; but my system is forever stuck in the past. Right now I solve this by manually calling chronyc burst 4/4 on OpenSuSE (chrony) or service ntp stop ntpd -gq service ntp start on antiX (ntpd). I wonder if there is some way to attach this to some hook that would fire once whenever the Internet comes up.

I have two machines, 1. host A with IP 192.168.0.1 2. host B with IP 192.168.0.2 They connected to the same network and I would like to set the date and time of machine B to match those of machine A. While I can set up the machines with an internet connection initially, they will not have access to it once deployed and they will be rebooted every day. **Current Approach using Chrony** Reference . *This configuration is not correct*, based on some test results, the synchronization succeeds when the NTP server has an internet connection and fails otherwise. Do you have any advice or suggestions for configuring them effectively? **Machine A - Configured as NTP server** sudo apt update && sudo apt upgrade sudo apt install chrony sudo vim /etc/chrony/chrony.conf Used this configuration to set up the NTP server confdir /etc/chrony/conf.d pool ntp.ubuntu.com iburst maxsources 4 pool 0.ubuntu.pool.ntp.org iburst maxsources 1 pool 1.ubuntu.pool.ntp.org iburst maxsources 1 pool 2.ubuntu.pool.ntp.org iburst maxsources 2 allow 192.168.0.0/24 sourcedir /run/chrony-dhcp sourcedir /etc/chrony/sources.d keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift ntsdumpdir /var/lib/chrony logdir /var/log/chrony maxupdateskew 100.0 rtcsync makestep 1 3 leapsectz right/UTC Restarted the chrony service, checked that was running and enabled it to start on boot sudo systemctl restart chrony sudo systemctl status chrony CTRL+C sudo systemctl enable chrony **Machine B - Configured as Chrony Client** Synced the date and time with a pool of servers and set the 192.168.0.1 sudo apt update && sudo apt upgrade sudo apt install chrony sudo vim /etc/chrony/chrony.conf Used the following configuration file pool 192.168.0.1 iburst prefer keyfile /etc/chrony/chrony.keys driftfile /var/lib/chrony/chrony.drift logdir /var/log/chrony log measurements statistics tracking maxupdateskew 100.0 rtcsync makestep 1.0 3 Restarted, checked the service and enabled it at startup sudo systemctl restart chrony sudo systemctl status chrony CTRL+C sudo systemctl enable chrony **Update** If I manually synchronize the time, I get the following error **No suitable source for synchronisation**. sudo systemctl stop chrony sudo chronyd -d 'server 192.168.0.1 iburst' 2023-03-15T15:54:55Z chronyd version 3.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHASH +IPV6 -DEBUG) 2023-03-15T15:54:55Z Initial frequency -36.773 ppm 2023-03-15T15:55:03Z No suitable source for synchronisation 2023-03-15T15:55:03Z chronyd exiting **Update 2** If I connect the NTP server to internet, then the synchronization succeeds.

I've seen a decent amount of documentation for how one would use a GPS and its PPS signal along with an NTP package (like ntpd or chrony) to synchronize the computer's clock. I have a need similar to this, but different enough that it's been complicated to see a straightforward solution. ### The constraints Note, my environment is inherently without internet access or GPS signal, and the up-time will be very short-lived, a couple hours at a time perhaps. Note, in this case we have an off-board micro-controller and a basic linux machine (likely some single board computer type thing), the ultimate goal is for these to be synchronized. The microcontroller is connected to this RTC (with I2C) and the computer (through USB) and will be handling timekeeping and synchronizing of some external sensors. The computer takes information from the sensors and does various other things with it. Ethernet connection between linux machine and MCU is generally not possible, otherwise I would just use something like PTP or NTP more directly. #### Difference from GPS PPS The main difference here from the GPS PPS, is that the computer needs to read from the microcontroller serial communication for our purposes in addition to the synchronization. From my understanding this means we need modifications from the standard gpsd + ntpd/chrony since these two sources (our application and gpsd) can't simultaneously read from the same USB serial. #### Limitations Note, I am aware that this will not reach GPS levels of drift. What I need is a synchronized time source between my MCU and computer which is accurate to some number of milliseconds. I can accept that this whole systems drifts with 1-3PPM (the RTC) as long as everything drifts together. #### Idea for a solution My idea so far would be upon PPS signal from the external RTC - RTC PPS captured by MCU and linux machines GPIO pins - MCU sends (over serial) corresponding unixstamp to our application node (on linux machine) Our application then makes the PPS signal and unixstamp available to chrony. Which at this point should be able to treat it as if it was a GPS. So I'm basically circumventing gpsd so I don't have to share serial port access. Could this make sense? I have found almost nothing from other people doing something similar

I am attempting to use a USB GPS without PPS dongle as the sole time source on Ubuntu 18.04. GPSD appears to be working correctly since cgps reports a 3D fix. However, I can't get chrony to see the GPS information.

# gpsd -ND 8 /dev/ttyUSB0
gpsd:INFO: launching (Version 3.17)
gpsd:IO: opening IPv4 socket
gpsd:SPIN: passivesock_af() -> 3
gpsd:IO: opening IPv6 socket
gpsd:SPIN: passivesock_af() -> 4
gpsd:INFO: listening on port gpsd
gpsd:PROG: NTP: shmat(4718600,0,0) succeeded, segment 0
gpsd:PROG: NTP: shmat(4751369,0,0) succeeded, segment 1
gpsd:PROG: NTP: shmat(4784139,0,0) succeeded, segment 2
gpsd:PROG: NTP: shmat(4816908,0,0) succeeded, segment 3
gpsd:PROG: NTP: shmat(4849677,0,0) succeeded, segment 4
gpsd:PROG: NTP: shmat(4882446,0,0) succeeded, segment 5
gpsd:PROG: NTP: shmat(4915215,0,0) succeeded, segment 6
gpsd:PROG: NTP: shmat(4947984,0,0) succeeded, segment 7
gpsd:PROG: successfully connected to the DBUS system bus
gpsd:PROG: shmget(0x47505344, 8936, 0666) for SHM export succeeded
gpsd:PROG: shmat() for SHM export succeeded, segment 4980753
gpsd:INFO: stashing device /dev/ttyUSB0 at slot 0
gpsd:INFO: running with effective group ID 20
gpsd:INFO: running with effective user ID 128
gpsd:INFO: startup at 2022-12-06T16:50:17.000Z (1670345417)

chrony.conf:

refclock SHM 0 poll 3 refid gps1
keyfile /etc/chrony/chrony.keys
driftfile /var/lib/chrony/chrony.drift
logdir /var/log/chrony
maxupdateskew 10
rtcsync
makestep 1 3

# chronyd -df /etc/chrony/chrony.conf
2022-12-06T16:52:15Z chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SECHASH +SIGND +ASYNCDNS +IPV6 -DEBUG)
2022-12-06T16:52:15Z Frequency -22.003 +/- 4.168 ppm read from /var/lib/chrony/chrony.drift

# chronyc sources
210 Number of sources = 1
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#? GPS0                          0   4     0     -     +0ns[   +0ns] +/-    0ns

I think the issue is related to shared memory since I think chrony/gpsd should be utilizing SHM ID 0 but it doesn't seem to exist.

# ipcs -m

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 262144     localuser    600        67108864   2          dest         
0x00000000 229377     localuser    600        16777216   2          dest         
0x00000000 360450     localuser    600        524288     2          dest         
0x00000000 393219     localuser    600        524288     2          dest         
0x00000000 491524     localuser    600        524288     2          dest         
0x00000000 5177349    localuser    600        524288     2          dest         
0x00000000 5210118    localuser    600        524288     2          dest         
0x00000000 655367     localuser    600        524288     2          dest         
0x4e545030 4718600    root       600        96         2                       
0x4e545031 4751369    root       600        96         1                       
0x00000000 2293770    localuser    600        16777216   2          dest         
0x4e545032 4784139    root       666        96         1                       
0x4e545033 4816908    root       666        96         1                       
0x4e545034 4849677    root       666        96         1                       
0x4e545035 4882446    root       666        96         1                       
0x4e545036 4915215    root       666        96         1                       
0x4e545037 4947984    root       666        96         1                       
0x47505344 4980753    root       666        8936       1                       
0x00000000 5472274    localuser    600        16384      2          dest         
0x4e9c5038 5570579    root       600        96         0                       
0x00000000 5308436    localuser    600        532480     2          dest         
0x00000000 5341205    localuser    600        532480     2          dest         
0x00000000 5439510    localuser    600        16384      2          dest         
0x4ea05041 5603351    root       600        96         0

I've tried starting chronyd before gpsd and that didn't help. Any ideas? Am I missing something obvious? Thanks in advance. Similar question: Using gpsd and chrony without pulse per second Another source I've read: GPSD Time Service HOWTO