3

I have some Ubuntu 18.04.1 servers. They all show this service being started rougly every 10 minutes.

Jan  7 06:29:05 csrf-prod1-vm dbus-daemon[434]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.12841' (uid=0 pid=25418 comm="timedatectl " label="unconfined")
Jan  7 06:29:05 csrf-prod1-vm systemd[1]: Starting Time & Date Service...
Jan  7 06:29:05 csrf-prod1-vm dbus-daemon[434]: [system] Successfully activated service 'org.freedesktop.timedate1'
Jan  7 06:29:05 csrf-prod1-vm systemd[1]: Started Time & Date Service.

Perhaps of note is I have configured timesyncd with some network-local ntp servers.

$ timedatectl status
                      Local time: Mon 2019-01-07 18:15:54 UTC
                  Universal time: Mon 2019-01-07 18:15:54 UTC
                        RTC time: Mon 2019-01-07 18:15:55
                       Time zone: Etc/UTC (UTC, +0000)
       System clock synchronized: yes
systemd-timesyncd.service active: yes
                 RTC in local TZ: no

It appears that this service just starts systemd-timedated. Is this what's used by systemd-timesyncd in order to set the time? Why does it not stay running as the suffix d[aemon] would suggest? Or is it redundant to systemd-timesyncd and should be disabled in some way?

OrangeDog
  • 618

2 Answers2

2

It turns out that a configuration management system was calling timedatectl every ~10 minutes in order to check the current timezone.

This calls timedate1 over DBUS to get the answer, which only activates on incoming messages.

So entirely normal, and entirely my fault.

OrangeDog
  • 618
2

systemd-timesyncd is one-shot so it's more of an SNTP client rather than an NTP one. I've seen situations where it was triggered each time you get a DHCP lease and if your leases have a short period it is triggered frequently. The snippet of the log you enclosed doesn't give enough information though - that just looks like one activation and start...

Anon
  • 1,293