I am running pre-built SD card image for the raspberry pi of nextcloudpi , but I figure I might get better help here. I noticed that the time and date was not automatically updated so I started debugging. I noticed that all lines in the file /etc/systemd/timesyncd.conf were commented out and the NTP line was empty. There's no additional timesyncd.conf.d subdirectory. So I uncommented lines and populated the NTP line. Here's how timesyncd.conf file looks now:

[Time]
NTP=0.europe.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048
ConnectionRetrySec=30
SaveIntervalSec=60

It seems that the content is parsed successfully because:

pi@nextcloudpi:~$ timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=0.europe.pool.ntp.org
RuntimeNTPServers=
FallbackNTPServers=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
ServerName=
ServerAddress=
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=0
Frequency=0

However:

pi@nextcloudpi:~$ timedatectl
               Local time: Sat 2024-12-28 12:05:31 EET
           Universal time: Sat 2024-12-28 10:05:31 UTC
                 RTC time: n/a
                Time zone: Europe/Helsinki (EET, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no

pi@nextcloudpi:~$ timedatectl timesync-status
       Server: n/a (n/a)
Poll interval: 0 (min: 32s; max 34min 8s)
 Packet count: 0

The System clock synchronized always indicates no and the Server is always n/a. I tried

sudo timedatectl set-ntp false
sudo timedatectl set-ntp true

but it didn't change anything. The systemd-timesyncd service is running:

● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
             └─override.conf
     Active: active (running) since Fri 2024-12-27 22:38:50 EET; 13h ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 3014 (systemd-timesyn)
     Status: "Daemon is running"
      Tasks: 1 (limit: 761)
     Memory: 576.0K
        CPU: 920ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─3014 /lib/systemd/systemd-timesyncd

I tried enabling debug logging of this service, but nothing useful is printed there. There's never anything like Connecting to time server. It's not even trying. I also tried manually updating with ntpdate

sudo ntpdate -vd pool.ntp.org

and that worked fine. So I assume that this rules out possible DNS and other network related issues. I ran out of ideas. What am I missing here? Here's the version info:

pi@nextcloudpi:~$ sudo lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Armbian-unofficial 24.8.2 bookworm
Release:        12
Codename:       bookworm

pi@nextcloudpi:~$ cat /etc/armbian-release
# PLEASE DO NOT EDIT THIS FILE
BOARD=rpi4b
BOARD_NAME="Raspberry Pi 4"
BOARDFAMILY=bcm2711
BUILD_REPOSITORY_URL=https://github.com/armbian/build 
BUILD_REPOSITORY_COMMIT=549f321
LINUXFAMILY=bcm2711
ARCH=arm64
BOOT_SOC=
IMAGE_TYPE=user-built
BOARD_TYPE=conf
INITRD_ARCH=arm64
KERNEL_IMAGE_TYPE=Image
FORCE_BOOTSCRIPT_UPDATE=
FORCE_UBOOT_UPDATE=
VENDOR="Armbian-unofficial"
VENDORDOCS="https://docs.armbian.com/ "
VENDORURL="https://duckduckgo.com/ "
VENDORSUPPORT="https://community.armbian.com/ "
VENDORBUGS="https://armbian.atlassian.net/ "
VERSION=24.8.2
REVISION=24.8.2

Edit:

pi@nextcloudpi:~$ ntpq -np
-bash: ntpq: command not found

pi@nextcloudpi:~$ systemctl status ntp
Unit ntp.service could not be found.

Edit 2: So it seems to be a network related issue somehow. Until now I have been connected through WiFi only. But immediately when I connected also the Ethernet cable, the System clock synchronized turned to yes. But why is it not working over WiFi? Here's resolvectl status when connected to WiFi only:

Global
         Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 1.0.0.1
        DNS Servers 1.0.0.1

Link 2 (enxb827ebf2575c)
Current Scopes: none
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 3 (wlan0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

When the Ethernet cable is connected, it is otherwise the same, except for the Link 2 part:

Link 2 (enxb827ebf2575c)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.1
       DNS Servers: 192.168.1.1

Both WiFi and the Ethernet are the same network.

I'm developing a custom Linux distribution with yocto (Zeus Release). I'm using systemd-timesyncd as NTP Client. I need to substitute its default configuration file (/etc/systemd/timesyncd.conf) with a custom configuration file. I know that the NTP client systemd-timesyncd is installed into the image by the recipe meta/recipes-core/systemd/systemd_245.6.bb. In the recipe are present the followed lines:

PACKAGECONFIG ??= " \
    ...
    timesyncd \
    ...
"

and others. Furthermore in the same recipe it is defined the configuration file timesyncd.conf by the followed lines:

CONFFILES_${PN} = "${sysconfdir}/systemd/coredump.conf \
    ...
    ${sysconfdir}/systemd/timesyncd.conf \
    ...
"

I have found [this post](https://stackoverflow.com/questions/77915145/bitbake-way-to-add-a-system-conf-setting) which explains how to substitute the default configuration file /etc/systemd/system.conf by an other defined by a user. Since the two configuration files (timesyncd.conf and system.conf) are installed in the same folder, /etc/systemd/, I have created an append file /recipes-core/systemd/systemd-conf_%.bbappend and followed the other steps well described in the post, but, after the image building, the timesyncd.conf remains the default one and it is not substitute by my custom configuration file. So, how can I substitute the default timesyncd.conf file in the yocto image?

### Configuration of systemd-timesyncd ### On my linux distribution I'm using the NTP client systemd-timesyncd. Its configuration file (/etc/systemd/timesyncd.conf) is:

[Time]
NTP=192.168.127.11
FallbackNTP=192.168.127.11
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

where 192.168.127.11 is the IP address of a Lubuntu workstation where is installed the package ntp. The Lubuntu workstation is **offline** (it is not connected to any other host other than the linux distribution where is in execution the systemd-timesyncd client). ### NTP Server configuration ### The Lubuntu workstation (ip address 192.168.127.201) executes the service ntpsec.service with the following configuration file /etc/ntpsec/ntp.conf:

# /etc/ntpsec/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

# This should be maxclock 7, but the pool entries count towards maxclock.
tos maxclock 11

# Comment this out if you have a refclock and want it to be able to discipline
# the clock by itself (e.g. if the system is not connected to the network).
#tos minclock 4 minsane 3

# Specify one or more NTP servers.

# Public NTP servers supporting Network Time Security:
# server time.cloudflare.com nts

# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See https://www.pool.ntp.org/join.html  for
# more information.
#pool 0.ubuntu.pool.ntp.org iburst
#pool 1.ubuntu.pool.ntp.org iburst
#pool 2.ubuntu.pool.ntp.org iburst
#pool 3.ubuntu.pool.ntp.org iburst

# Use Ubuntu's ntp server as a fallback.
#server ntp.ubuntu.com
server 127.127.1.0
fudge 127.127.1.0 stratum 1

# By default, exchange time with everybody, but don't allow configuration.
restrict default kod nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

### systemd-timesyncd is in Idle ### systemd-timesyncd client is in the "Idle" Status as showed by the following output message:

systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: disabled)
     Active: active (running) since Thu 2025-07-10 10:28:13 CEST; 7min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 71449 (systemd-timesyn)
     Status: "Idle."
      Tasks: 2 (limit: 2199)
     Memory: 860.0K
     CGroup: /system.slice/systemd-timesyncd.service
             └─71449 /lib/systemd/systemd-timesyncd

Jul 10 10:28:12  systemd: Starting Network Time Synchronization...
Jul 10 10:28:13  systemd: Started Network Time Synchronization.

### Wireshark captured ### By Wireshark I can see that client and server exchange some datagrams. In the response datagram of the Server I can see the following information:

Frame 4379: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0
Ethernet II, Src:  (), Dst:  ()
Internet Protocol Version 4, Src: 192.168.127.11, Dst: 192.168.127.201
User Datagram Protocol, Src Port: 123, Dst Port: 45358
Network Time Protocol (NTP Version 4, server)
    Flags: 0xe4, Leap Indicator: unknown (clock unsynchronized), Version number: NTP Version 4, Mode: server
        11.. .... = Leap Indicator: unknown (clock unsynchronized) (3)
        ..10 0... = Version number: NTP Version 4 (4)
        .... .100 = Mode: server (4)
    Peer Clock Stratum: unspecified or invalid (0)
    Peer Polling Interval: invalid (0)
    Peer Clock Precision: 0,000000 sec
    Root Delay: 0 seconds
    Root Dispersion: 0,0037841796875 seconds
    Reference ID: (Initialization)
    Reference Timestamp: Jan  1, 1970 00:00:00.000000000 UTC
    Origin Timestamp: Jul 10, 2025 09:07:50.163961034 UTC
    Receive Timestamp: Jul 10, 2025 09:14:44.087945767 UTC
    Transmit Timestamp: Jul 10, 2025 09:14:44.088197457 UTC

In this captured datagram I would highlight the Flags byte=0xe4 and in particular the 2 bits:

11.. .... = Leap Indicator: unknown (clock unsynchronized)  # in the Flags byte

Furthermore I highlight the 2 bytes (equal to 0):

Peer Clock Stratum: unspecified or invalid (0)
Peer Polling Interval: invalid (0)

I have noted that with an other NTP server the byte Peer Clock Stratum is equal to 1 and the client is able to synchronize its date and time. ### Question ### Why in my context the service systemd-timesyncd is not able to synchronize to my offline NTP Server? ### links read but not useful ### I have checked many posts (for example [this link](https://unix.stackexchange.com/questions/323348/ntp-client-not-synchronizing-from-a-private-ntp-server) or [this other](https://unix.stackexchange.com/questions/714732/system-clock-not-synchronized-with-ntp-server-using-systemd-timesyncd)) but none of these have been useful.

On my Linux distribution I'm using the NTP client systemd-timesyncd. ### Test case ### The test case is: 1. Boot while the system is able to reach the NTP server (that is time1.google.com) by a connection to a Wi-Fi network. 2. systemd-timesyncd is able to synchronize to the server as we can see by this log on journald:

Jun 03 10:38:24  systemd-timesyncd: Initial synchronization to time server 216.239.35.0:123 (time1.google.com).

3. Disconnection of the system from the Wi-Fi network: the NTP server is no longer reachable. 4. systemd-timesyncd does not give any warning that the server is unreachable. ### Workaround: restart the service ### To know that the server is not reachable I need to restart the systemd-timesyncd service. After the restart of the service, the file /run/systemd/timesync/synchronized is not present so I can programmatically know that the NTP server is not reachable. Without the restart the file /run/systemd/timesync/synchronized is still present so it seems that client and server are synchronized. **NOTE**: also after the restart in the journald of the service systemd-timesyncd does not appear any log about the fact that the NTP server time1.google.com is not reachable. ### Question ### There is an other way than restart the systemd-timesyncd service to know the synchronization status between the client and the server NTP? --- **EDIT** After the step number 4 described in the post, it is not possible to see by timedatectl status that systemd-timesyncd is not synchronized to the server. Below there is the output of the timedatectl command:

> timedatectl status
               Local time: Tue 2025-06-03 12:02:30 CEST
           Universal time: Tue 2025-06-03 10:02:30 UTC 
                 RTC time: Tue 2025-06-03 10:02:29     
                Time zone: Europe/Rome (CEST, +0200)   
System clock synchronized: yes                         
              NTP service: active                      
          RTC in local TZ: no

When running timedatectl to check if my system clock has been synchronized via NTP I get the following:

~> timedatectl
Failed to query server: The name org.freedesktop.timedate1 was not provided by any .service files

systemd-timedated.service has ran.

~> systemctl status systemd-timedated.service
● systemd-timedated.service - Time & Date Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-timedated.service; static; vendor preset: enabled)
     Active: inactive (dead)
       Docs: man:systemd-timedated.service(8)
             man:localtime(5)
             https://www.freedesktop.org/wiki/Software/systemd/timedated 

Mar 23 14:28:16 cm1sd systemd: Starting Time & Date Service...
Mar 23 14:28:16 cm1sd systemd: Started Time & Date Service.
Mar 23 14:29:00 cm1sd systemd: systemd-timedated.service: Succeeded.

Looking online I haven't found anything talking about this error message. How can I use systemd and timedatectl to have my system clock synchronized with an NTP server? I've also noted nothing under /etc/systemd/ defines the NTP server to use. I'm on an embedded Linux system, built using Buildroot, systemd version 244.5.

When I query the status of the NTP daemon with ntpdc -c sysinfo I get the following output: system peer: 0.0.0.0 system peer mode: unspec leap indicator: 11 stratum: 16 precision: -20 root distance: 0.00000 s root dispersion: 12.77106 s reference ID: [73.78.73.84] reference time: 00000000.00000000 Thu, Feb 7 2036 7:28:16.000 system flags: auth monitor ntp kernel stats jitter: 0.000000 s stability: 0.000 ppm broadcastdelay: 0.000000 s authdelay: 0.000000 s This indicates that the NTP sync failed. However the system time is accurate within 1 second precision. When I ran my system without network connection for the same period as I did now the system time would deviate ~10s. This behavior suggests that the system has another way of syncing the time. I realized that there is also systemd-timesyncd.service (with configuration file at /etc/systemd/timesyncd.conf) and timedatectl status gives me the correct time: Local time: Thu 2016-08-25 10:55:23 CEST Universal time: Thu 2016-08-25 08:55:23 UTC RTC time: Thu 2016-08-25 08:55:22 Time zone: Europe/Berlin (CEST, +0200) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: yes Last DST change: DST began at Sun 2016-03-27 01:59:59 CET Sun 2016-03-27 03:00:00 CEST Next DST change: DST ends (the clock jumps one hour backwards) at Sun 2016-10-30 02:59:59 CEST Sun 2016-10-30 02:00:00 CET So my question is what is the difference between the two mechanisms? Is one of them deprecated? Can they be used in parallel? Which one should I trust when I want to query the NTP sync status? (Note that I have a different system (in a different network) for which both methods indicate success and yield the correct time.)

I have a raspberry pi running Raspbian bullseye. On it, I have a software installed that does the following every 30 seconds: - logs data to a mariadb database - publishes the data via a rest api - publishes the data via MQTT On irregular instances (about every few days), - the data stops being logged to mariadb and - ssh stops working ("kex_exchange_identification: read: Connection reset by peer") - but rest api and MQTT still work fine, so the machine is still up. I think the problem is related to time syncing, any help to further investigate is highly appreciated. Here is what I've got so far: journalctl -u systemd-timesyncd --no-hostname --since "1 day ago"

-- Boot d689dc8fa3c1460a9e301ea7e3d024e4 --
Jul 06 23:17:10 systemd-timesyncd: System clock time unset or jumped backwards, restoring from recorded timestamp: Sat 2024-07-06 23:44:05 CEST
Jul 06 23:44:05 systemd: Started Network Time Synchronization.
Jul 06 23:44:45 systemd-timesyncd: Timed out waiting for reply from 144.76.43.40:123 (0.de.pool.ntp.org).
Jul 07 07:41:32 systemd-timesyncd: Initial synchronization to time server 116.202.171.176:123 (0.de.pool.ntp.org).
-- Boot 1833ccc33db04f41af2486ff4a4bc63a --
Jul 06 23:17:13 systemd-timesyncd: System clock time unset or jumped backwards, restoring from recorded timestamp: Sun 2024-07-07 07:45:17 CEST
Jul 07 07:45:17 systemd: Started Network Time Synchronization.
Jul 07 07:45:57 systemd-timesyncd: Timed out waiting for reply from 178.63.9.212:123 (0.de.pool.ntp.org).
Jul 07 07:47:07 systemd-timesyncd: Initial synchronization to time server 141.144.230.32:123 (0.de.pool.ntp.org).

systemd-analyze dot systemd-timesyncd.service

digraph systemd {
        "time-set.target"->"systemd-timesyncd.service" [color="green"];
        "systemd-timesyncd.service"->"systemd-tmpfiles-setup.service" [color="green"];
        "systemd-timesyncd.service"->"system.slice" [color="green"];
        "systemd-timesyncd.service"->"-.mount" [color="green"];
        "systemd-timesyncd.service"->"systemd-remount-fs.service" [color="green"];
        "systemd-timesyncd.service"->"systemd-sysusers.service" [color="green"];
        "systemd-timesyncd.service"->"systemd-journald.socket" [color="green"];
        "systemd-timesyncd.service"->"system.slice" [color="black"];
        "systemd-timesyncd.service"->"-.mount" [color="black"];
        "systemd-timesyncd.service"->"time-set.target" [color="grey66"];
        "systemd-timesyncd.service"->"time-sync.target" [color="grey66"];
        "systemd-timesyncd.service"->"shutdown.target" [color="red"];
        "shutdown.target"->"systemd-timesyncd.service" [color="green"];
        "vzlogger.service"->"systemd-timesyncd.service" [color="green"];
        "sysinit.target"->"systemd-timesyncd.service" [color="green"];
        "sysinit.target"->"systemd-timesyncd.service" [color="grey66"];
}

sudo systemctl status systemd-timesyncd.service

● systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2024-07-07 07:45:17 CEST; 6min ago
       Docs: man:systemd-timesyncd.service(8)
   Main PID: 369 (systemd-timesyn)
     Status: "Initial synchronization to time server 141.144.230.32:123 (0.de.pool.ntp.org)."
      Tasks: 2 (limit: 3932)
        CPU: 292ms
     CGroup: /system.slice/systemd-timesyncd.service
             └─369 /lib/systemd/systemd-timesyncd

timedatectl status

Local time: So 2024-07-07 07:52:12 CEST
           Universal time: So 2024-07-07 05:52:12 UTC
                 RTC time: n/a
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

cat /lib/systemd/system/systemd-timesyncd.service

#  [commented out general info]
[Unit]
Description=Network Time Synchronization
Documentation=man:systemd-timesyncd.service(8)
ConditionCapability=CAP_SYS_TIME
ConditionVirtualization=!container
DefaultDependencies=no
After=systemd-sysusers.service
Before=time-set.target sysinit.target shutdown.target
Conflicts=shutdown.target
Wants=time-set.target time-sync.target
[Service]
AmbientCapabilities=CAP_SYS_TIME
BusName=org.freedesktop.timesync1
CapabilityBoundingSet=CAP_SYS_TIME
ExecStart=!!/lib/systemd/systemd-timesyncd
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProtectProc=invisible
ProtectControlGroups=yes
ProtectHome=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectSystem=strict
Restart=always
RestartSec=0
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
RuntimeDirectory=systemd/timesync
StateDirectory=systemd/timesync
SystemCallArchitectures=native
SystemCallErrorNumber=EPERM
SystemCallFilter=@system-service @clock
Type=notify
User=systemd-timesync
WatchdogSec=3min
[Install]
WantedBy=sysinit.target

cat /etc/systemd/system/systemd-timesyncd.timer

: /etc/systemd/system/systemd-timesyncd.timer: No such file or directory

cat /etc/systemd/timesyncd.conf

#  [commented out general info]
[Time]
NTP=0.de.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Edit: Thanks for the hints. I installed chrony and changed the NTP servers, let's see if anything changes. So far, no issue. Second edit: problem arised today again, here is some info that might help you: The system rebootet three times within a short timespan (from journalctl):

-- Boot b1fe1bcf01554348828247969af37f88 --
Jul 09 12:17:01 raspberrypi kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd083]
Jul 09 12:17:01 raspberrypi kernel: Linux version 6.1.21-v8+ (dom@buildbot) (aarch64-linux-gnu-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023
Jul 09 12:17:01 raspberrypi kernel: random: crng init done
Jul 09 12:17:01 raspberrypi kernel: Machine model: Raspberry Pi 4 Model B Rev 1.2
-- Boot c7607911dbbe4ed7b10cf3df812b2c16 --
Jul 09 12:17:01 raspberrypi CRON: pam_unix(cron:session): session closed for user root
-- Boot b1fe1bcf01554348828247969af37f88 --

and then it showed some issues:

Jul 09 12:17:36 raspberrypi bluetoothd: profiles/sap/server.c:sap_server_register() Sap driver initialization failed.
Jul 09 12:17:36 raspberrypi bluetoothd: sap-server: Operation not permitted (1)
Jul 09 12:17:36 raspberrypi bluetoothd: Failed to set mode: Rejected (0x0b)
Jul 09 12:17:36 raspberrypi bluetoothd: Failed to set mode: Rejected (0x0b)
Jul 09 12:17:36 raspberrypi bluetoothd: Failed to set privacy: Rejected (0x0b)
Jul 09 12:17:36 raspberrypi dbus-daemon: [system] Successfully activated service 'org.freedesktop.hostname1'
Jul 09 12:17:36 raspberrypi systemd: Started Hostname Service.
Jul 09 12:17:36 raspberrypi pulseaudio: Failed to find a working profile.
Jul 09 12:17:36 raspberrypi pulseaudio: Failed to load module "module-alsa-card" (argument: "device_id="1" name="platform-fef00700.hdmi" card_name="alsa_card.platform-fef00700.hdmi" namereg_fail=false tsched=no fixed_lat>
Jul 09 12:17:36 raspberrypi pulseaudio: Failed to find a working profile.
Jul 09 12:17:36 raspberrypi pulseaudio: Failed to load module "module-alsa-card" (argument: "device_id="2" name="platform-fef05700.hdmi" card_name="alsa_card.platform-fef05700.hdmi" namereg_fail=false tsched=no fixed_lat>

Then, another reboot (no error message before that):

-- Boot b1fe1bcf01554348828247969af37f88 --
Jul 09 12:18:03 raspberrypi chronyd: Selected source 185.183.159.238 (2.debian.pool.ntp.org)
Jul 09 12:18:03 raspberrypi chronyd: System clock wrong by 6401.522525 seconds
Jul 09 14:04:45 raspberrypi chronyd: System clock was stepped by 6401.522525 seconds
Jul 09 14:04:45 raspberrypi chronyd: System clock TAI offset set to 37 seconds

My ntp service running well but I can't start timedatectl, any one can help? # systemctl status ntp ● ntp.service - LSB: Start NTP daemon Loaded: loaded (/etc/init.d/ntp; generated; vendor preset: enabled) Active: active (exited) since Sat 2020-06-13 01:37:35 UTC; 2min 37s ago Docs: man:systemd-sysv-generator(8) Tasks: 0 (limit: 19660) CGroup: /system.slice/ntp.service Jun 13 01:37:35 localhost systemd: Stopped LSB: Start NTP daemon. Jun 13 01:37:35 localhost systemd: Starting LSB: Start NTP daemon... Jun 13 01:37:35 localhost systemd: Started LSB: Start NTP daemon. # timedatectl Failed to query server: Cannot send after transport endpoint shutdown

I use systemd-timesyncd to run NTP time synchronization. I want to specify two servers, one company internal (not available from outside), and one from the public internet: [Time] NTP=ntp.mycompany.net FallbackNTP=pool.ntp.org However, if the device is outside the company network and the internal server is not available, timesyncd never switches over to the FallbackNTP. user@device:~# timedatectl timesync-status Server: n/a (ntp.mycompany.net) Poll interval: 0 (min: 32s; max 34min 8s) Packet count: 0 What am I overlooking here? Thanks!

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?

I followed [this answer here](https://unix.stackexchange.com/a/666973) , but it seems that my system clock doesn't synchronize with NTP server:

$ cat /etc/debian_version
10.9
$ egrep -v "^$|^#" /etc/systemd/timesyncd.conf
[Time]
NTP=x.y.z.t1
FallbackNTP=x.y.z.t2
$ sudo timedatectl set-ntp true
$ sudo systemctl restart systemd-timesyncd
$ systemctl status systemd-timesyncd
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Wed 2022-08-24 16:46:29 CEST; 2ms ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 23412 (systemd-timesyn)
   Status: "Idle."
    Tasks: 2 (limit: 4915)
   Memory: 1.4M
   CGroup: /system.slice/systemd-timesyncd.service
           └─23412 /lib/systemd/systemd-timesyncd

Aug 24 16:46:29 EncoderBack systemd: Starting Network Time Synchronization...
Aug 24 16:46:29 EncoderBack systemd: Started Network Time Synchronization.
$ timedatectl timesync-status
       Server: x.y.z.t1 (x.y.z.t1)
Poll interval: 1min 4s (min: 32s; max 34min 8s)
 Packet count: 0
$ timedatectl show-timesync
SystemNTPServers=x.y.z.t1
FallbackNTPServers=x.y.z.t2
ServerName=x.y.z.t1
ServerAddress=x.y.z.t1
RootDistanceMaxUSec=5s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=34min 8s
PollIntervalUSec=1min 4s
Frequency=0
$ journalctl -u systemd-timesyncd.service -n 5
-- Logs begin at Mon 2022-08-22 15:20:05 CEST, end at Wed 2022-08-24 16:46:29 CEST. --
Aug 24 16:46:29 EncoderBack systemd: Stopping Network Time Synchronization...
Aug 24 16:46:29 EncoderBack systemd: systemd-timesyncd.service: Succeeded.
Aug 24 16:46:29 EncoderBack systemd: Stopped Network Time Synchronization.
Aug 24 16:46:29 EncoderBack systemd: Starting Network Time Synchronization...
Aug 24 16:46:29 EncoderBack systemd: Started Network Time Synchronization.
$ timedatectl status
               Local time: Wed 2022-08-24 16:46:29 CEST
           Universal time: Wed 2022-08-24 14:46:29 UTC
                 RTC time: Wed 2022-08-24 14:46:19
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: no
              NTP service: active
          RTC in local TZ: no
$

EDIT0 : Here is a [tcpdump](https://www.tcpdump.org/manpages/tcpdump.1.html) trace while restarting systemd-timesyncd.service :

$ sudo tcpdump -v dst port 123
tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:46:34.136278 IP (tos 0x10, ttl 64, id 18841, offset 0, flags [DF], proto UDP (17), length 76)
    ntpclient.lan.53695 > ntpserver.lan.ntp: NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 0
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   3870427594.031728329 (2022/08/25 16:46:34)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 3870427594.031728329 (2022/08/25 16:46:34)
^C
1 packet captured
1 packet received by filter
0 packets dropped by kernel

EDIT1 : Here is a [tshark](https://www.wireshark.org/docs/man-pages/tshark.html) trace while restarting systemd-timesyncd.service :

$ sudo tshark -n -f 'udp port 123' -c2
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
    1 0.000000000 a.b.c.d  → x.y.z.t1 NTP 90 NTP Version 4, client
    2 0.000678872 x.y.z.t1 → a.b.c.d  NTP 90 NTP Version 3, server
C2 packets captured

EDIT2 : Thanks to @Bib and to the tshark output, it seems the systemd-timesyncd client sends NTPv4 protocol requests but the server responds with NTPv3 protocol answers. As @QuartzCristal and @Bib suggest, I will be using ntpsec. EDIT3: After having configured the /etc/ntpsec/ntp.conf file and restarted the ntpsec service, it works fine now :

$ grep ^server /etc/ntpsec/ntp.conf
server x.y.z.t1 iburst
server x.y.z.t2 iburst
$ sudo mkdir /var/log/ntpsec/
$ sudo chown ntpsec:ntpsec /var/log/ntpsec/
$ sudo systemctl restart ntpsec
$ systemctl status ntpsec.service
● ntpsec.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntpsec.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2022-08-26 11:06:49 CEST; 2s ago
     Docs: man:ntpd(8)
  Process: 22622 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 22625 (ntpd)
    Tasks: 1 (limit: 4915)
   Memory: 1.6M
   CGroup: /system.slice/ntpsec.service
           └─22625 /usr/sbin/ntpd -p /run/ntpd.pid -c /etc/ntpsec/ntp.conf -g -N -u ntpsec:ntpsec

Aug 26 11:06:49 EncoderBack ntpd: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2021-12-28T00:00Z last=2017-01-01T00:00Z ofs=37
Aug 26 11:06:49 EncoderBack ntpd: CLOCK: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): expired less than 242 days ago
Aug 26 11:06:49 EncoderBack ntpd: INIT: Using SO_TIMESTAMPNS
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen and drop on 0 v6wildcard [::]:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen normally on 2 lo 127.0.0.1:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen normally on 3 eno1 a.b.c.d:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen normally on 4 lo [::1]:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listen normally on 5 eno1 [fe80::3e7c:3fff:fed4:a223%2]:123
Aug 26 11:06:49 EncoderBack ntpd: IO: Listening on routing socket on fd #22 for interface updates

Now the system clock is synchronized :

$ timedatectl
               Local time: Fri 2022-08-26 11:08:05 CEST
           Universal time: Fri 2022-08-26 09:08:05 UTC
                 RTC time: Fri 2022-08-26 09:08:05
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: n/a
          RTC in local TZ: no

EDIT4 : Here is a tcpdump output of what is going on when using ntpsec, the source packet tos has changed and the source port is now 123 :

$ sudo tcpdump dst port 123 -n -c 2 -v
tcpdump: listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:53:49.185280 IP (tos 0xb8, ttl 64, id 54505, offset 0, flags [DF], proto UDP (17), length 76)
    a.b.c.d.123 > x.y.z.t1: NTPv4, length 48
        Client, Leap indicator:  (0), Stratum 0 (unspecified), poll 0 (1s), precision 32
        Root Delay: 0.000000, Root dispersion: 0.000000, Reference-ID: (unspec)
          Reference Timestamp:  0.000000000
          Originator Timestamp: 0.000000000
          Receive Timestamp:    0.000000000
          Transmit Timestamp:   1839874488.898661747 (2094/05/28 04:43:04)
            Originator - Receive Timestamp:  0.000000000
            Originator - Transmit Timestamp: 1839874488.898661747 (2094/05/28 04:43:04)
11:53:49.185929 IP (tos 0x0, ttl 126, id 18818, offset 0, flags [none], proto UDP (17), length 76)
    x.y.z.t1.123 > a.b.c.d.123: NTPv3, length 48
        Server, Leap indicator:  (0), Stratum 1 (primary reference), poll 0 (1s), precision -23
        Root Delay: 0.000000, Root dispersion: 10.751129, Reference-ID: LOCL
          Reference Timestamp:  3870431575.277677199 (2022/08/25 17:52:55)
          Originator Timestamp: 1839874488.898661747 (2094/05/28 04:43:04)
          Receive Timestamp:    3870496473.230674199 (2022/08/26 11:54:33)
          Transmit Timestamp:   3870496473.230678499 (2022/08/26 11:54:33)
            Originator - Receive Timestamp:  +2030621984.332012452
            Originator - Transmit Timestamp: +2030621984.332016752
2 packets captured
2 packets received by filter
0 packets dropped by kernel

And here is a tshark output of what is going on when using ntpsec, the weird is that it is the same output as the one I got from using systemd-timesyncd.service (except the source port is now 123) :

$ sudo tshark -f 'udp port 123' -n -c 2
Running as user "root" and group "root". This could be dangerous.
Capturing on 'eno1'
    1 0.000000000 a.b.c.d  → x.y.z.t1 NTP 90 NTP Version 4, client
    2 0.000787978 x.y.z.t1 → a.b.c.d  NTP 90 NTP Version 3, server
2 packets captured

I'm trying to start systemd-timesyncd on Archlinux that was installed via Distrod on top of WSL. By default systemd-timesyncd's unit file prevents it from starting up on virtualized environment, the unit file has a ConditionVirtualization=!container flag. I'm trying to override this with the following configuration:

[root@valentine ~]# systemd-detect-virt
wsl
[root@valentine ~]# cat /etc/systemd/system/systemd-timesyncd.service.d/override.conf
[Unit]
ConditionVirtualization=wsl
[root@valentine ~]# systemctl daemon-reload
[root@valentine ~]# systemctl start systemd-timesyncd.service
[root@valentine ~]# systemctl status systemd-timesyncd.service
○ systemd-timesyncd.service - Network Time Synchronization
     Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/systemd-timesyncd.service.d
             └─override.conf
     Active: inactive (dead)
  Condition: start condition failed at Mon 2023-02-27 10:38:46 CET; 6s ago
             └─ ConditionVirtualization=!container was not met
       Docs: man:systemd-timesyncd.service(8)

Feb 27 10:38:46 valentine systemd: Network Time Synchronization was skipped because of an unmet condition check (ConditionVirtualization=!container).

It seems like systemd is picking p the override configuration, yet, it doesn't seem to use the overridden configuration flag. What's the best way to solve this issue and have systemd-timesyncd run in a virtualized envrionment?

On an Archlinux host, I noticed that command timedatectl status returned correct result for times (local and UTC) but also mentioned that the NTP service was inactive. That struck me as odd because ntpd.service is enabled and active on that machine, even though systemd-timesynd.service is present but not enabled. On https://unix.stackexchange.com/a/542959/72707 I saw that provided the systemd-timesync.service is available, doing:

# timedatectl set-ntp true

is enough to show an active NTP service in the output of timedatectl status. I also saw that it automatically enabled and activated systemd-timesync.service. Hence my question:\ Do I need the ntpd.service at all ? Is there a differentiated need for both systemd-timesync.service and ntpd.service?

I am on Ubuntu server 18.04 and the clock do not sync :~$ timedatectl status Local time: jeu. 2022-12-22 09:36:48 CET Universal time: jeu. 2022-12-22 08:36:48 UTC RTC time: n/a Time zone: Europe/Paris (CET, +0100) System clock synchronized: no systemd-timesyncd.service active: yes RTC in local TZ: no Trying to start the service : sudo systemctl restart systemd-timesyncd.service Job for systemd-timesyncd.service failed because the control process exited with error code. See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details. Status : systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2022-12-22 09:26:36 CET; 9min ago Docs: man:systemd-timesyncd.service(8) Process: 28171 ExecStart=/lib/systemd/systemd-timesyncd (code=exited, status=227/NO_NEW_PRIVILEGES) Main PID: 28171 (code=exited, status=227/NO_NEW_PRIVILEGES) I cannot figure out why it does not work

systemd-timesyncd unit fails on my Pi 4B running Linux 5.10.103-v7l+

openhabian@openhab:~ $ systemctl -a --failed
  UNIT                      LOAD   ACTIVE SUB    DESCRIPTION                 
● systemd-timesyncd.service loaded failed failed Network Time Synchronization

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

1 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

openhabian@openhab:~ $

I can see in journalctl that systemd-timesyncd is starting and stopping until it fails for too many attempts:

@openhab:~ $ journalctl -u systemd-timesyncd
-- Logs begin at Sat 2022-12-03 07:12:50 CST, end at Sat 2022-12-03 11:23:56 CST. --
Dec 03 11:20:27 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:20:27 openhab systemd: Started Network Time Synchronization.
Dec 03 11:20:27 openhab systemd-timesyncd: Synchronized to time server for the first time 198.137.202.56:123 (0.debian.pool.ntp.org).
Dec 03 11:21:44 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:21:44 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:21:44 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:21:44 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:21:44 openhab systemd: Started Network Time Synchronization.
Dec 03 11:21:44 openhab systemd-timesyncd: Synchronized to time server for the first time 202.22.158.104:123 (0.debian.pool.ntp.org).
Dec 03 11:22:25 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:25 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:25 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:25 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:26 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:26 openhab systemd-timesyncd: Synchronized to time server for the first time 198.206.184.196:123 (0.debian.pool.ntp.org).
Dec 03 11:22:37 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:37 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:37 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:37 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:37 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:37 openhab systemd-timesyncd: Synchronized to time server for the first time 198.206.184.196:123 (0.debian.pool.ntp.org).
Dec 03 11:22:38 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:38 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:38 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:38 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:38 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:38 openhab systemd-timesyncd: Synchronized to time server for the first time 147.182.158.78:123 (0.debian.pool.ntp.org).
Dec 03 11:22:39 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:39 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:39 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:39 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:39 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:40 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:40 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:40 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:40 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:40 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:41 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:41 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:41 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:41 openhab systemd: Starting Network Time Synchronization...
Dec 03 11:22:41 openhab systemd: Started Network Time Synchronization.
Dec 03 11:22:42 openhab systemd: Stopping Network Time Synchronization...
Dec 03 11:22:42 openhab systemd: systemd-timesyncd.service: Succeeded.
Dec 03 11:22:42 openhab systemd: Stopped Network Time Synchronization.
Dec 03 11:22:42 openhab systemd: systemd-timesyncd.service: Start request repeated too quickly.
Dec 03 11:22:42 openhab systemd: systemd-timesyncd.service: Failed with result 'start-limit-hit'.
Dec 03 11:22:42 openhab systemd: Failed to start Network Time Synchronization.

I tried running it with debug logging using the same user that is running it, systemd-timesync:

@openhab:~ $ sudo -u systemd-timesync SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-timesyncd
Failed to get link NTP servers: No data available
Bus bus-api-timesync: changing state UNSET → OPENING
Bus bus-api-timesync: changing state OPENING → AUTHENTICATING
Added new server 0.debian.pool.ntp.org.
Added new server 1.debian.pool.ntp.org.
Added new server 2.debian.pool.ntp.org.
Added new server 3.debian.pool.ntp.org.
systemd-timesyncd running as pid 30632
Selected server 0.debian.pool.ntp.org.
Resolving 0.debian.pool.ntp.org...
Bus bus-api-timesync: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.1680 path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=n/a error-message=n/a
Bus bus-api-timesync: changing state HELLO → RUNNING
Got message type=signal sender=org.freedesktop.DBus.Local destination=n/a path=/org/freedesktop/DBus/Local interface=org.freedesktop.DBus.Local member=Connected cookie=4294967295 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.1680 path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.1680 path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=3 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.1680 path=n/a interface=n/a member=n/a cookie=4 reply_cookie=2 signature=u error-name=n/a error-message=n/a
Successfully acquired requested service name.
Resolved address 168.61.215.74:123 for 0.debian.pool.ntp.org.
Resolved address 69.89.207.199:123 for 0.debian.pool.ntp.org.
Resolved address 73.239.136.185:123 for 0.debian.pool.ntp.org.
Resolved address 45.55.58.103:123 for 0.debian.pool.ntp.org.
Selected address 168.61.215.74:123 of server 0.debian.pool.ntp.org.
Connecting to time server 168.61.215.74:123 (0.debian.pool.ntp.org).
Sent NTP request to 168.61.215.74:123 (0.debian.pool.ntp.org).
NTP response:
  leap         : 0
  version      : 3
  mode         : 4
  stratum      : 3
  precision    : 0.000000 sec (-23)
  root distance: 0.025322 sec
  reference    : n/a
  origin       : 1669861973.494
  receive      : 1669861973.578
  transmit     : 1669861973.578
  dest         : 1669861973.522
  offset       : +0.070 sec
  delay        : +0.028 sec
  packet count : 1
  jitter       : 0.000
  poll interval: 32
  adjust (slew): +0.070 sec
Failed to call clock_adjtime(): Operation not permitted

This shows why it is failing. If I run it as root using sudo, I don't get that error and it appears to be working:

@openhab:~ $ sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-timesyncd
[sudo] password for openhabian: 
Failed to get link NTP servers: No data available
Bus bus-api-timesync: changing state UNSET → OPENING
Bus bus-api-timesync: changing state OPENING → AUTHENTICATING
Added new server 0.debian.pool.ntp.org.
Added new server 1.debian.pool.ntp.org.
Added new server 2.debian.pool.ntp.org.
Added new server 3.debian.pool.ntp.org.
systemd-timesyncd running as pid 7506
Selected server 0.debian.pool.ntp.org.
Resolving 0.debian.pool.ntp.org...
Bus bus-api-timesync: changing state AUTHENTICATING → HELLO
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Sent message type=method_call sender=n/a destination=org.freedesktop.DBus path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=RequestName cookie=2 reply_cookie=0 signature=su error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.1802 path=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 signature=s error-name=n/a error-message=n/a
Bus bus-api-timesync: changing state HELLO → RUNNING
Got message type=signal sender=org.freedesktop.DBus.Local destination=n/a path=/org/freedesktop/DBus/Local interface=org.freedesktop.DBus.Local member=Connected cookie=4294967295 reply_cookie=0 signature=n/a error-name=n/a error-message=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.1802 path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Got message type=signal sender=org.freedesktop.DBus destination=:1.1802 path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=3 reply_cookie=0 signature=s error-name=n/a error-message=n/a
Got message type=method_return sender=org.freedesktop.DBus destination=:1.1802 path=n/a interface=n/a member=n/a cookie=4 reply_cookie=2 signature=u error-name=n/a error-message=n/a
Successfully acquired requested service name.
Resolved address 91.236.251.14:123 for 0.debian.pool.ntp.org.
Resolved address 212.26.18.43:123 for 0.debian.pool.ntp.org.
Resolved address 196.10.52.58:123 for 0.debian.pool.ntp.org.
Resolved address 91.209.0.17:123 for 0.debian.pool.ntp.org.
Selected address 91.236.251.14:123 of server 0.debian.pool.ntp.org.
Connecting to time server 91.236.251.14:123 (0.debian.pool.ntp.org).
Sent NTP request to 91.236.251.14:123 (0.debian.pool.ntp.org).
NTP response:
  leap         : 0
  version      : 4
  mode         : 4
  stratum      : 2
  precision    : 0.000000 sec (-22)
  root distance: 0.036522 sec
  reference    : n/a
  origin       : 1670079231.584
  receive      : 1670079230.147
  transmit     : 1670079230.147
  dest         : 1670079231.735
  offset       : -1.513 sec
  delay        : +0.151 sec
  packet count : 1
  jitter       : 0.000
  poll interval: 32
  adjust (jump): -1.513 sec
  status       : 8192 sync
  time now     : 1670079230.223
  constant     : 2
  offset       : +0.000 sec
  freq offset  : +243704 (+3 ppm)
interval/delta/delay/jitter/drift 32s/-1.513s/0.151s/0.000s/+3ppm
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/timesync1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=3 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Synchronized to time server for the first time 91.236.251.14:123 (0.debian.pool.ntp.org).
Sent NTP request to 91.236.251.14:123 (0.debian.pool.ntp.org).
NTP response:
  leap         : 0
  version      : 4
  mode         : 4
  stratum      : 2
  precision    : 0.000000 sec (-22)
  root distance: 0.037010 sec
  reference    : n/a
  origin       : 1670079262.294
  receive      : 1670079262.371
  transmit     : 1670079262.371
  dest         : 1670079262.448
  offset       : -0.000 sec
  delay        : +0.154 sec
  packet count : 2
  jitter       : 0.000
  poll interval: 64
  adjust (slew): -0.000 sec
  status       : 8193 sync
  time now     : 1670079262.448
  constant     : 2
  offset       : -0.000 sec
  freq offset  : +243704 (+3 ppm)
interval/delta/delay/jitter/drift 64s/-0.000s/0.154s/0.000s/+3ppm
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/timesync1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=4 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a
Sent NTP request to 91.236.251.14:123 (0.debian.pool.ntp.org).
NTP response:
  leap         : 0
  version      : 4
  mode         : 4
  stratum      : 2
  precision    : 0.000000 sec (-22)
  root distance: 0.037971 sec
  reference    : n/a
  origin       : 1670079326.544
  receive      : 1670079326.621
  transmit     : 1670079326.621
  dest         : 1670079326.699
  offset       : -0.000 sec
  delay        : +0.154 sec
  packet count : 3
  jitter       : 0.000
  poll interval: 128
  adjust (slew): -0.000 sec
  status       : 8193 sync
  time now     : 1670079326.699
  constant     : 3
  offset       : -0.000 sec
  freq offset  : +119863 (+1 ppm)
interval/delta/delay/jitter/drift 128s/-0.000s/0.154s/0.000s/+1ppm
Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/timesync1 interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=5 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a

So I think I need to somehow give the system user systemd-timesync the right permission, but I have no idea how to do that. Here are the users: root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/bin/bash list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin systemd-timesync:x:100:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin systemd-network:x:101:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:102:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin _apt:x:103:65534::/nonexistent:/usr/sbin/nologin messagebus:x:104:110::/nonexistent:/usr/sbin/nologin _rpc:x:105:65534::/run/rpcbind:/usr/sbin/nologin statd:x:106:65534::/var/lib/nfs:/usr/sbin/nologin sshd:x:107:65534::/run/sshd:/usr/sbin/nologin avahi:x:108:113:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/usr/sbin/nologin systemd-coredump:x:996:996:systemd Core Dumper:/:/usr/sbin/nologin openhabian:x:1000:115:,,,:/home/openhabian:/bin/bash avahi-autoipd:x:109:114:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/usr/sbin/nologin openhab:x:110:115:openhab2 runtime user,,,:/var/lib/openhab:/bin/false dnsmasq:x:111:65534:dnsmasq,,,:/var/lib/misc:/usr/sbin/nologin mosquitto:x:112:118::/var/lib/mosquitto:/usr/sbin/nologin frontail:x:1001:1001::/var/tmp:/bin/bash Debian-exim:x:113:119::/var/spool/exim4:/usr/sbin/nologin

I'm in a bit of a pickle here. I have a bunch of Ubuntu 22.04 VMs, hosted on multiple ESXi servers. When I try to apply netplan using netplan apply, system networking freezes and no packets are sent (checked with tcpdump). Also, when I try to install systemd-timesyncd and enable ntp service, same thing happens. I've tried different things, including tweaks on keepalived parameters in kernel, but no luck so far... Any ideas why this happens? --- **Netplan config** (as per [Artem's](https://unix.stackexchange.com/users/260833/artem-s-tashkinov) comment)

network:
  version: 2
  ethernets:
    ens160:
      dhcp4: no
      dhcp6: no
      optional: true
      match:
        macaddress: "00:50:56:94:c2:1a"
      addresses:
      - 172.16.96.31/20
      nameservers:
        addresses:
        - 172.16.1.3
      routes:
      - to: 0.0.0.0/0
        via: 172.16.1.3
        on-link: true
      - to: 172.16.1.0/24 
        via: 172.16.111.254
      - to: 172.18.0.0/16 
        via: 172.16.111.254
      - to: 172.16.53.104/32 
        via: 172.16.111.254
      - to: 172.16.8.0/24 
        via: 172.16.111.254
      - to: 172.16.56.0/24 
        via: 172.16.111.254
      - to: 172.16.96.0/20 
        via: 172.16.111.254
      - to: 172.16.49.0/24 
        via: 172.16.111.254

P.S 1: I added match to point out to the exact MAC Address on my network interface as part of my efforts, but it didn't solve the problem.

timedatectl produces the following output:

Local time: Tue 2022-05-10 01:07:46 UTC
           Universal time: Tue 2022-05-10 01:07:46 UTC
                 RTC time: Tue 2022-05-10 01:07:46    
                Time zone: Etc/UTC (UTC, +0000)       
System clock synchronized: yes                        
              NTP service: active                     
          RTC in local TZ: no

I see that the system clock is synchronized with NTP, but how synchronized is "synchronized"? How frequently is NTP consulted, and if the connection to the NTP server is lost, at what point will the system decide that the clock is no longer in sync?

I've recently upgraded to pop_os 21.10 from 21.04 and every time I boot my device I get random time/date set on my machine. Automatic date and time under settings is not working. The following is the output of timedatectl : Local time: Wed 2022-02-23 10:43:32 IST Universal time: Wed 2022-02-23 05:13:32 UTC RTC time: Wed 2019-07-24 03:48:55 Time zone: Asia/Kolkata (IST, +0530) System clock synchronized: no NTP service: active RTC in local TZ: no I've tried running timedatectl set-ntp true to enable system clock sync but it doesn't work. Also tried [this](https://askubuntu.com/a/1046217/1573526) solution for a similar problem with Ubuntu 18.04 which suggests adding a @restart param to crontab config but that doesn't work too.

I'm trying to set-up a Raspberry Pi with read-only filesystems. The base image is the debian buster lite raspbian image. Most stuff is working, e.g. had to do simple fixes like:

mv /etc/resolv.conf /var/run/resolv.conf && ln -s /var/run/resolv.conf /etc/resolv.conf

Similar for dhcp and a few other services However, there is one service that I would like to get working, that refuses to work like this: systemd-timesync. Here's what I did and what happens.systemd-timesync I created a directory /run/systemd-timesync, owned by user systemd-timesync:systemd-timesync Then created a symlink /var/lib/systemd/timesync -> /run/systemd-timesync root@raspberrypi:/var/lib/systemd # ls -l /var/lib/systemd/timesync lrwxrwxrwx 1 root root 21 Dec 25 14:48 /var/lib/systemd/timesync -> /run/systemd-timesync root@raspberrypi:/var/lib/systemd # ls -l /run/systemd-timesync/ total 0 -rw-r--r-- 1 systemd-timesync systemd-timesync 0 Dec 25 15:02 clock The relevant part of the systemd unit file: ... [Service] User=systemd-timesync AmbientCapabilities=CAP_SYS_TIME CapabilityBoundingSet=CAP_SYS_TIME WorkingDirectory=/run/systemd-timesync Environment=SYSTEMD_LOG_LEVEL=debug ExecStartPre=/bin/pwd ExecStart=!!/lib/systemd/systemd-timesyncd ... RuntimeDirectory=systemd/timesync StateDirectory=systemd/timesync ... Note that I added a ExecStartPre=/bin/pwd which should just output the current working directory to the journal. Now if I start the systemd-timesync with / mounted as read-only, this is what happens root@raspberrypi:/var/lib/systemd # systemctl stop systemd-timesyncd.service && systemctl daemon-reload && systemctl start systemd-timesyncd.service Job for systemd-timesyncd.service failed because of unavailable resources or another system error. See "systemctl status systemd-timesyncd.service" and "journalctl -xe" for details. The output of journalctl Dec 25 15:34:10 raspberrypi systemd: systemd-timesyncd.service: Trying to enqueue job systemd-timesyncd.service/stop/replace Dec 25 15:34:10 raspberrypi systemd: systemd-timesyncd.service: Installed new job systemd-timesyncd.service/stop as 1214 Dec 25 15:34:10 raspberrypi systemd: systemd-timesyncd.service: Enqueued job systemd-timesyncd.service/stop as 1214 Dec 25 15:34:10 raspberrypi systemd: systemd-timesyncd.service: Job 1214 systemd-timesyncd.service/stop finished, result=done Dec 25 15:34:10 raspberrypi systemd: /lib/systemd/system/systemd-timesyncd.service:36: Failed to parse system call, ignoring: io_pgetevents Dec 25 15:34:10 raspberrypi systemd: systemd-timesyncd.service: Changed dead -> failed Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Trying to enqueue job systemd-timesyncd.service/start/replace Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Installed new job systemd-timesyncd.service/start as 1215 Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Enqueued job systemd-timesyncd.service/start as 1215 Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionFileIsExecutable=!/usr/sbin/VBoxService succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionFileIsExecutable=!/usr/sbin/chronyd succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionFileIsExecutable=!/usr/sbin/openntpd succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionFileIsExecutable=!/usr/sbin/ntpd succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionVirtualization=!container succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: ConditionCapability=CAP_SYS_TIME succeeded. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Failed to run 'start-pre' task: Read-only file system Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Failed with result 'resources'. Dec 25 15:34:11 raspberrypi systemd: systemd-timesyncd.service: Job 1215 systemd-timesyncd.service/start finished, result=failed Dec 25 15:34:11 raspberrypi systemd: Failed to start Network Time Synchronization. Clearly the /bin/pwd from ExecStartPre fails because of the read-only filesystem. I do not understand this, and don't know how to work around it. If I remove the ExecStartPre the same happens with the ExecStart command. When I however do,

mount -o remount,rw /

and subsequently root@raspberrypi:/var/lib/systemd # systemctl stop systemd-timesyncd.service && systemctl daemon-reload && systemctl start systemd-timesyncd.service all works fine, including the pwd output to the journal. Similarly when I start root@raspberrypi:/var/lib/systemd # /lib/systemd/systemd-timesyncd Synchronized to time server for the first time 84.199.86.247:123 (0.debian.pool.ntp.org). all works fine. So far, my conclusion seems to be that systemd REQUIRES write-access somewhere to start any command in ExecStartPre or ExecStart. Any ideas on how I can achieve my original goal of having the raspberry update it's time settings? Note: it may be related to the lines StateDirectory, RuntimeDirectory in the unit file.

Is there any issue with running systemd-timesyncd and ntp on the same machine? I'm asking this because I have started using NTP on all servers but the systemd-timesyncd is running there as well. Should I disable it? Any issues with both running?