systemd-timesyncd

From ArchWiki
Jump to navigation Jump to search

From the systemd mailing list:

systemd-timesyncd is a daemon that has been added for synchronizing the system clock across the network. It implements an SNTP client. In contrast to NTP implementations such as chrony or the NTP reference server this only implements a client side, and does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it. Unless you intend to serve NTP to networked clients or want to connect to local hardware clocks this simple NTP client should be more than appropriate for most installations. The daemon runs with minimal privileges, and has been hooked up with networkd to only operate when network connectivity is available. The daemon saves the current clock to disk every time a new NTP sync has been acquired, and uses this to possibly correct the system clock early at bootup, in order to accommodate for systems that lack an RTC such as the Raspberry Pi and embedded devices, and make sure that time monotonically progresses on these systems, even if it is not always correct. To make use of this daemon a new system user and group "systemd-timesync" needs to be created on installation of systemd.

Configuration

Start/enable systemd-timesyncd.service which is available with systemd.

When starting, systemd-timesyncd will read the configuration file from /etc/systemd/timesyncd.conf, which looks like this:

/etc/systemd/timesyncd.conf
[Time]
#NTP=
#FallbackNTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

To add time servers or change the provided ones, uncomment the relevant line and list their host name or IP separated by a space. For example, you can use any servers provided by the NTP pool project or use the default Arch ones (also provided by the NTP pool project):

/etc/systemd/timesyncd.conf
[Time]
NTP=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org 0.fr.pool.ntp.org

To verify your configuration, use timedatectl show-timesync --all:

$ timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=
FallbackNTPServers=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
ServerName=0.arch.pool.ntp.org
ServerAddress=103.47.76.177
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=1min 4s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-21, RootDelay=177.398ms, RootDispersion=142.196ms, Reference=C342F10A, OriginateTimestamp=Mon 2018-07-16 13:53:43 +08, ReceiveTimestamp=Mon 2018-07-16 13:53:43 +08, TransmitTimestamp=Mon 2018-07-16 13:53:43 +08, DestinationTimestamp=Mon 2018-07-16 13:53:43 +08, Ignored=no PacketCount=1, Jitter=0 }
Frequency=22520548

Further to the daemon configuration, NTP servers may also be provided via a systemd-networkd configuration with a NTP= option or, dynamically, via a DHCP server.

The NTP server to be used will be determined using the following rules:

  • Any per-interface NTP servers obtained from systemd-networkd.service(8) configuration or via DHCP take precedence.
  • The NTP servers defined in /etc/systemd/timesyncd.conf will be appended to the per-interface list at runtime and the daemon will contact the servers in turn until one is found that responds.
  • If no NTP server information is acquired after completing those steps, the NTP server host names or IP addresses defined in FallbackNTP= will be used.
Note: The service writes to a local file /var/lib/systemd/timesync/clock with every synchronization. This location is hard-coded and cannot be changed. This may be problematic for running off read-only root partition or trying to minimize writes to an SD card.

Usage

To enable and start it, simply run:

# timedatectl set-ntp true 

The synchronization process might be noticeably slow. This is expected, one should wait a while before determining there is a problem. To check the service status, use timedatectl status:

$ timedatectl status
               Local time: Thu 2015-07-09 18:21:33 CEST
           Universal time: Thu 2015-07-09 16:21:33 UTC
                 RTC time: Thu 2015-07-09 16:21:33
                Time zone: Europe/Amsterdam (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

To see verbose service information, use timedatectl timesync-status:

$ timedatectl timesync-status
       Server: 103.47.76.177 (0.arch.pool.ntp.org)
Poll interval: 2min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C342F10A
    Precision: 1us (-21)
Root distance: 231.856ms (max: 5s)
       Offset: -19.428ms
        Delay: 36.717ms
       Jitter: 7.343ms
 Packet count: 2
    Frequency: +267.747ppm

Troubleshooting

systemd-timesyncd fails to start after systemd 242.0-1 update

If log shows this error:

ExecStart=/usr/lib/systemd/systemd-timesyncd (code=exited, status=238/STATE_DIRECTORY)

Execute the following commands to fix the issue:

# rm -rf /var/lib/systemd/timesync
# rm -rf /var/lib/private/systemd/timesync

See FS#62161.

Dynamically set NTP servers received via DHCP

Tango-edit-clear.pngThis article or section needs language, wiki syntax or style improvements. See Help:Style for reference.Tango-edit-clear.png

Reason: Written like a blog post. See Help:Style#Language register. (Discuss in Talk:Systemd-timesyncd#)

Tango-go-next.pngThis article or section is a candidate for moving to NetworkManager#Dispatcher examples.Tango-go-next.png

Notes: Belongs on the NetworkManager page, not in this troubleshooting section. (Discuss in Talk:Systemd-timesyncd#)

Presupposition:

  • Your system clock is synchonized with NTP servers by systemd-timesyncd.
  • Your networks are configured by NetworkManager.

If you roam between different networks (e.g. you company's LAN, your wifi at home, various other wifis now and then) you might want to set the NTP server(s) used by timesyncd to those provided by DHCP. Contrary to systemd-networkd NetworkManager is not capable to communicate with systemd-timesyncd to set the NTP server(s).

NetworkManager dispatcher to the rescue! (All following actions have to be performed as root. So either spin up a root shell with sudo -i or prepend all commands with sudo.)

If not already existing create the overlay directory for your systemd-timesyncd configuration /etc/systemd/timesyncd.conf.d. Also if not already existing create the directory /etc/NetworkManager/dispatcher.d. Put the following dispatcher script there

/etc/NetworkManager/dispatcher.d/10-update-timesyncd
#! /usr/bin/bash

[ -n "$CONNECTION_UUID" ] || exit

INTERFACE=$1
ACTION=$2

case $ACTION in
    up | dhcp4-change | dhcp6-change)
        [ -n "$DHCP4_NTP_SERVERS" ] || exit
        exec > /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf
        echo "[Time]"
        echo "NTP=$DHCP4_NTP_SERVERS"
        systemctl restart systemd-timesyncd
        ;;
    down)
        rm -f /etc/systemd/timesyncd.conf.d/$CONNECTION_UUID.conf
        systemctl restart systemd-timesyncd
        ;;
esac

Make this script executable by root only with chmod 700 10-update-timesync. Finally make sure NetworkManager dispatcher is enabled and started.

So what happens here? Every time NetworkManager sets up a new network connection (ACTION=up) or gets some update for an existing connection (ACTION=dhcp4-change or ACTION=dhcp6-change) and the provided connection data contains information about NTP server(s) (DHCP4_NTP_SERVERS) then a connection specific overlay configuration file is written to /etc/systemd/timesyncd.conf.d containing the provided NTP server(s). Whenever a connection is taken down (ACTION=down) the connection specific overlay file is removed again. After each change to the configuration of systemd-timesyncd this service is restarted to pick up the updated configuration.The use of connection specific config files is intentional so that when two or more connections are managed by NetworkManager in parallel the different NTP server names in the config are not overwritten as up, dhcp4-change, dhcp6-change and down actions might come in in an arbitrary order.

See also