Systemd-timesyncd takes several minutes during boot

hravnkel · July 17, 2024, 7:31am

I recently installed Lubuntu on my old Macbook Pro (late 2009). I am very satisfied with the overall experience, however I have a problem with boot time that seems to be related to a generally common problem - but I cannot find a suitable solution in any of the forum posts here or elsewhere.

Bottom line, after investigating the very long boot time I have found that the problem is here:

jul 17 08:16:15 hravnkelsmacbookpro systemd[1]: NetworkManager-dispatcher.service:
jul 17 08:21:09 hravnkelsmacbookpro systemd-timesyncd[538]: Contacted time server:

As you can see there’s a five minute wait before systemd-timesyncd is able to reach the server.

Anyone know of a way to continue with the boot and keep the timesync trying until it succeeds without stalling the entire process? Or should I approach this different?

I get the same problem no matter if I’m connected via ethernet or wifi.

Wolf314 · July 17, 2024, 7:59am

This issue is discussed on github:

github.com/systemd/systemd

systemd taking a lot of time during boot if it doesn't get network access

opened 02:23PM - 13 Apr 23 UTC

closed 12:39PM - 08 Jun 23 UTC

plomari

bug 🐛 pid1

### systemd version the issue has been seen with 252.6 ### Used distribution …Debian unstable ### Linux kernel version used 5.10.176 ### CPU architectures issue was seen on x86_64 ### Component systemd ### Expected behaviour you didn't see If there's a boot problem, systemd should give me the choice to continue booting and skipping whatever init thing causes problem, or dropping into a root shell. ### Unexpected behaviour you saw systemd waits several minutes (maybe just 1m30s, I don't remember) waiting for something that won't happen, then apparently gives up and continues booting. There doesn't seem to be any way to interact with. ### Steps to reproduce the problem Apparently systemd wants network access during boot, maybe to sync the clock with NTP. It appears that sometimes, the "stable" network interface names are not stable and change on boot. (Either it's random, or it happened with a minor upgrade within the 5.10 stable kernel series. All my network interfaces are connected with PCIe and no hotplug is going on, the hardware wasn't changed between the reboots.) Due to the mismatching names, my systemd-networkd configuration broke. systemd couldn't access the network. I suspect the timesyncd service stalled or failed. You may be able to reproduce the problem by taking your network card and plugging it into a different PCIe slot (or doing the equivalent with a VM). Or maybe you can just try to boot with the network cable unplugged. (I wonder how this works on laptops, they usually will not have network access during boot...) This specific problem is caused by networkd or timesyncd. But fundamentally there's a worse problem with systemd making you wait like an idiot until it's done with its timeout, with no way to intervene. There might be worse situations, which leave you with a hard to recover system. ### Additional program output to the terminal or log subsystem illustrating the issue _No response_

hravnkel · July 17, 2024, 11:10am

Ah, thank you for that link! That was indeed helpful for further investigation.

Alas - it seems like the problem was, as the thread implies, not truly related to systemd-timesyncd as I’ve tried to (first) replace it with NTP and then (second) disable all realtime clock synchronization and the error just moved.

It however is certainly related to network in some way, now I have a five minute wait before spa_supplicant[814]: wlan0: SME: Trying to authenticate with […my WiFi router…]

I will have to investigate further. Thank you for the link, helped me get a bit further.

system · August 16, 2024, 11:11am

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.