I am running systemd-resolvd for resolving dns on my laptop. For some reason, it takes 30 seconds after waking up from sleep /boot before it starts working. Any idea where to begin debugging this? I am using systemd-resolvd in order to make DNS work over my wirguard tunnel to my home network.
1 Like
Review the output of journalctl --since="5m ago" within 5 minutes of waking from sleep. Hopefully you’ll find a clue in there.
For instance, when I open the lid of my laptop, the journal contains interesting bits such as
Jun 09 07:09:47 farm kernel: Freezing user space processes
...
Jun 09 07:09:47 farm kernel: ACPI: PM: Waking up from system sleep state S3
...
Jun 09 07:09:47 farm kernel: OOM killer enabled.
Jun 09 07:09:47 farm kernel: Restarting tasks ...
...
Jun 09 07:09:47 farm systemd-resolved[1727]: Clock change detected. Flushing caches.
Jun 09 07:09:47 farm systemd-logind[2682]: Lid opened.
Jun 09 07:09:47 farm systemd-sleep[176897]: System returned from sleep state.
Jun 09 07:09:47 farm kernel: PM: suspend exit
Jun 09 07:09:47 farm systemd[1]: systemd-suspend.service: Deactivated successfully.
Jun 09 07:09:47 farm systemd[1]: Finished System Suspend.
Jun 09 07:09:47 farm systemd[1]: Stopped target Sleep.
Jun 09 07:09:47 farm systemd[1]: Reached target Suspend.
Jun 09 07:09:47 farm systemd-logind[2682]: Operation 'sleep' finished.
Jun 09 07:09:47 farm NetworkManager[2667]: <info> [1686319787.6408] manager: sleep: wake requested (sleeping: yes enabled: yes)
Jun 09 07:09:47 farm NetworkManager[2667]: <info> [1686319787.6410] device (wlp170s0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
...
Jun 09 07:09:51 farm NetworkManager[2667]: <info> [1686319791.1314] dhcp4 (wlp170s0): activation: beginning transaction (timeout in 45 seconds)
Jun 09 07:09:51 farm systemd-resolved[1727]: wlp170s0: Bus client set default route setting: yes
Jun 09 07:09:51 farm systemd-resolved[1727]: wlp170s0: Bus client set DNS server list to: 2606:4700:4700::1111, 2606:4700:4700::1001
Jun 09 07:09:51 farm NetworkManager[2667]: <info> [1686319791.6246] device (enp0s13f0u3): carrier: link connected
Jun 09 07:09:51 farm NetworkManager[2667]: <info> [1686319791.6250] device (enp0s13f0u3): state change: unavailable -> disconnected (reason 'carrier-changed', sys-iface-state: 'managed')
Jun 09 07:09:51 farm kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp0s13f0u3: link becomes ready
Jun 09 07:09:51 farm kernel: r8152 12-3:1.0 enp0s13f0u3: carrier on
...
Jun 09 07:09:56 farm NetworkManager[2667]: <info> [1686319796.7139] dhcp6 (enp0s13f0u3): activation: beginning transaction (timeout in 45 seconds)
Jun 09 07:09:56 farm NetworkManager[2667]: <info> [1686319796.7158] dhcp6 (enp0s13f0u3): state changed new lease, address=fdca:4ad6:5530::5a6
Jun 09 07:09:56 farm systemd-resolved[1727]: enp0s13f0u3: Bus client set default route setting: yes
...
Jun 09 07:10:03 farm NetworkManager[2667]: <info> [1686319803.9298] dhcp4 (enp0s13f0u3): state changed new lease, address=10.0.45.208
Jun 09 07:10:03 farm NetworkManager[2667]: <info> [1686319803.9302] manager: NetworkManager state is now CONNECTED_SITE
Jun 09 07:10:03 farm NetworkManager[2667]: <info> [1686319803.9302] policy: set 'Auto Ethernet' (enp0s13f0u3) as default for IPv4 routing and DNS
Jun 09 07:10:03 farm systemd-resolved[1727]: wlp170s0: Bus client set default route setting: no
Jun 09 07:10:03 farm systemd-resolved[1727]: wlp170s0: Bus client reset DNS server list.
Jun 09 07:10:03 farm systemd-resolved[1727]: enp0s13f0u3: Bus client set search domain list to: lan
Jun 09 07:10:03 farm systemd-resolved[1727]: enp0s13f0u3: Bus client set DNS server list to: 10.0.45.1
Jun 09 07:10:13 farm systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
In this case, my laptop has wifi and USB-ethernet connections. NetworkManager processes WiFi first, which takes about 4s before resolved is notified. The ethernet connection takes another 5s. Then another 7s pass getting an IPv4 address before resolved is notified the IPv4 net is up.
This seems like a ridiculously long time to bring up the network, but I’ve never before looked at why. I suspect that NetworkManager handles the interfaces (mostly) serially, and there are some long timeout values.
If I recall correctly, IPv4 config is delayed to give preference to IPv6. My network routes only IPv4 but possibly has some broken IPv6 pieces active. Likely I could significantly reduce the network activation time if I fixed IPv6 routing or configured everything properly to use only IPv4.