[Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

probackup-nl · 2024-01-17 17:09:40

My system is equipped with a Real Time Clock. Thus I don't see much need waiting for systemd-timesyncd.service on every (re)boot.

systemd-analyze critical-chain

multi-user.target @9.885s
└─systemd-logind.service @8.689s +1.194s
  └─basic.target @8.281s
    └─dbus-broker.service @8.054s +199ms
      └─dbus.socket @7.852s
        └─sysinit.target @7.686s
          └─systemd-timesyncd.service @6.983s +702ms
            └─systemd-tmpfiles-setup.service @6.100s +778ms
              └─local-fs.target @6.035s
                └─tmp.mount @5.956s +77ms
                  └─swap.target @5.931s
                    └─dev-disk-by\x2duuid-b87678ab\x2d47aa\x2d4d15\x2d990f\x2d7ceb9d08c7a2.swap @5.749s +171ms
                      └─dev-disk-by\x2duuid-b87678ab\x2d47aa\x2d4d15\x2d990f\x2d7ceb9d08c7a2.device @5.728s

systemctl list-dependencies systemd-timesyncd.service --reverse

systemd-timesyncd.service
● └─sysinit.target
○   ├─archlinux-keyring-wkd-sync.service
●   ├─archlinux-keyring-wkd-sync.timer
●   ├─clamav-daemon.service
●   ├─clamav-daemon.socket
●   ├─clamav-freshclam.service
●   ├─dbus.socket
●   ├─dhcpcd.service
●   ├─dropbear.service
●   ├─getty@tty1.service
○   ├─logrotate.service
●   ├─logrotate.timer
●   ├─powertop.service
○   ├─shadow.service
●   ├─shadow.timer
○   ├─systemd-ask-password-wall.service
●   ├─systemd-logind.service
○   ├─systemd-pcrphase.service
●   ├─systemd-tmpfiles-clean.timer
●   ├─systemd-user-sessions.service
●   ├─xwall.service
●   ├─basic.target
○   │ ├─initrd.target
●   │ └─multi-user.target
●   │   ├─powertop.service
●   │   └─xwall.service
○   └─rescue.target

How safe or unsafe is it to try to get systemd-timesyncd.service out of the way, no longer delay the boot process?
Or are there other ways to reduce to boot delay cause by systemd-timesyncd.service?

I case it is safe, how to best start systemd-timesyncd.service delayed?
For example after reaching multi-user.target?

PS1 I prefer a fast remote login using dropbear.

Last edited by probackup-nl (2024-01-18 14:48:39)

Head_on_a_Stick · 2024-01-17 18:08:24

I think you're reading too much into the command output. Read the man page, it explains the limitations of the measurements, of which there are many. In short: it doesn't tell you how long it takes to reach a usable desktop at all.

Does your desktop take a long time to get to a usable state? You can disable systemd-timesyncd completely to test if it makes a noticeable difference. If it does I will eat my Shoei

PS I don't understand the last sentence in your post at all.

probackup-nl · 2024-01-17 19:03:48

https://man.archlinux.org/man/systemd-timesyncd.8 states:

systemd-timesyncd initialization delays the start of units that are ordered after time-set.target

Is

# systemctl list-dependencies time-set.target --after

the correct command to view which units are order after time-set.target?

Note: my output of the above command is:

time-set.target
● └─systemd-timesyncd.service

May I conclude there there are no units set to start after time-set.target?

Raynman · 2024-01-17 19:23:49

From that you can conclude that time-set.target has an After=systemd-timesyncd.service dependency, but you already got that from the latter's man page. You want --before.

tekstryder · 2024-01-17 19:48:55

Another tool is the boot plot.

$ systemd-analyze plot > boot.svg

May provide a clearer picture, quite literally.

probackup-nl · 2024-01-17 21:42:02

Raynman wrote:

You want --before.

--before is a much longer list:

# systemctl list-dependencies time-set.target --before
time-set.target
● ├─archlinux-keyring-wkd-sync.timer
● ├─logrotate.timer
● ├─paccache.timer
● ├─shadow.timer
○ ├─systemd-tmpfiles-clean.service
○ ├─shutdown.target
○ │ ├─systemd-soft-reboot.service
○ │ └─final.target
○ │   └─systemd-soft-reboot.service
○ └─time-sync.target
●   ├─archlinux-keyring-wkd-sync.timer
●   ├─logrotate.timer
●   ├─paccache.timer
●   ├─shadow.timer
○   └─shutdown.target
○     ├─systemd-soft-reboot.service
○     └─final.target
○       └─systemd-soft-reboot.service

Still no clue on how to delay starting systemd-timesyncd.service

May be there is no point in delaying systemd-timesyncd.service, because none of the units listed with --before are shown in the output of systemd-analyze critical-chain?

Last edited by probackup-nl (2024-01-17 21:58:36)

probackup-nl · 2024-01-18 09:26:35

No clue what changed, after the last reboot with kernel 6.7.0-arch3-1 efistub booted the systemd-timesyncd.service is much lower, only +64 ms:

multi-user.target @2.168s
└─systemd-logind.service @2.065s +102ms
  └─basic.target @1.994s
    └─dbus-broker.service @1.965s +24ms
      └─dbus.socket @1.963s
        └─sysinit.target @1.942s
          └─systemd-timesyncd.service @1.877s +64ms
            └─systemd-tmpfiles-setup.service @1.666s +188ms
              └─local-fs.target @1.622s
                └─boot.mount @1.562s +56ms
                  └─systemd-fsck@dev-disk-by\x2duuid-7BA0\x2d2A45.service @1.442s +91ms
                    └─dev-disk-by\x2duuid-7BA0\x2d2A45.device @1.411s

And quite consistent on every reboot:
systemd-timesyncd.service @1.917s +71ms
systemd-timesyncd.service @1.800s +63ms
systemd-timesyncd.service @1.983s +59ms
systemd-timesyncd.service @1.889s +75ms

I have no clue why the "The time the unit took to start" is now 10 times lower, thus faster booting.

What I do notice is that there is no sync done yet immediately after login:

systemd-analyze critical-chain && timedatectl timesync-status
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.

multi-user.target @2.179s
└─systemd-logind.service @2.065s +112ms
  └─basic.target @2.024s
    └─dbus-broker.service @1.988s +32ms
      └─dbus.socket @1.987s
        └─sysinit.target @1.964s
          └─systemd-timesyncd.service @1.889s +75ms
            └─systemd-tmpfiles-setup.service @1.704s +144ms
              └─local-fs.target @1.681s
                └─boot.mount @1.625s +55ms
                  └─systemd-fsck@dev-disk-by\x2duuid-7BA0\x2d2A45.service @1.512s +96ms
                    └─dev-disk-by\x2duuid-7BA0\x2d2A45.device @1.481s
       Server: n/a (1.nl.pool.ntp.org)
Poll interval: 0 (min: 32s; max 3d)
 Packet count: 0

Initially, something seem to trigger that the time need to be force synced, slowing down the boot process. My timesync settings are:

# timedatectl show-timesync --all
LinkNTPServers=
SystemNTPServers=0.nl.pool.ntp.org 1.nl.pool.ntp.org 2.nl.pool.ntp.org 3.nl.pool.ntp.org
RuntimeNTPServers=
FallbackNTPServers=0.arch.pool.ntp.org 1.arch.pool.ntp.org 2.arch.pool.ntp.org 3.arch.pool.ntp.org
ServerName=2.nl.pool.ntp.org
ServerAddress=87.233.197.123
RootDistanceMaxUSec=1s
PollIntervalMinUSec=32s
PollIntervalMaxUSec=3d
PollIntervalUSec=2min 8s
NTPMessage={ Leap=0, Version=4, Mode=4, Stratum=2, Precision=-23, RootDelay=1.113ms, RootDispersion=30.929ms, Reference=C14FED0E, OriginateTimestamp=Thu 2024-01-18 10:20:01 CET, ReceiveTimestamp=Thu 2024-01-18 10:20:01 CET, TransmitTimestamp=Thu 2024-01-18 10:20:01 CET, DestinationTimestamp=Thu 2024-01-18 10:20:01 CET, Ignored=no, PacketCount=3, Jitter=7.355ms }
Frequency=3159545

I should have noted my settings in the opening post, now it's difficult to figure out what was happening back then, isn't it?

seth · 2024-01-18 09:59:03

tekstryder wrote:

Another tool is the boot plot.
$ systemd-analyze plot > boot.svg
May provide a clearer picture, quite literally.

timesyncd typically will depend on establishing a network connection and that's most likely the variable here - the older journals might reveal that and perhaps why.

Arch Linux

#1 2024-01-17 17:09:40

[Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#2 2024-01-17 18:08:24

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#3 2024-01-17 19:03:48

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#4 2024-01-17 19:23:49

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#5 2024-01-17 19:48:55

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#6 2024-01-17 21:42:02

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#7 2024-01-18 09:26:35

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

#8 2024-01-18 09:59:03

Re: [Solved] Why boot delay by systemd-timesyncd.service +702ms vs +70?

Board footer