Public bug reported:
Warning: this summary was written by claude. I'm just a poor fella who
had to troubleshoot this and when the solution finally came to be, I
wanted to report this so no one else would have to suffer through this.
Summary: /etc/network/if-up.d/resolved blocks 90s per resolvectl call when
systemd-resolved is active before dbus.service, delaying boot by ~6 minutes
Ubuntu 26.04 LTS (upgraded from 24.04 LTS). Not reproducible on 24.04.
ifupdown: /etc/network/if-up.d/resolved
systemd 259 (259.5-0ubuntu3.3)
ii ifupdown 0.8.43ubuntu3 amd64 high level tools to configure
network interfaces
DESCRIPTION
The hook decides whether to push DNS config into resolved with:
if systemctl --quiet is-active systemd-resolved; then
resolvectl llmnr "$ifindex" yes || resolvectl_failed=$?
...
On 26.04, systemd-resolved is started very early via socket activation
(systemd-resolved-varlink.socket, systemd-resolved-monitor.socket), well
before dbus.service. ifup also runs early -- both networking.service and
[email protected] use DefaultDependencies=no. So is-active returns true, the
script commits to the resolvectl path, and every resolvectl call blocks
for the full 90s D-Bus timeout because there is no system bus yet.
With dns-nameservers on a static interface that is 4 calls (llmnr, mdns,
domain, dns) = 6 minutes. An interface with both inet and inet6 stanzas
runs the hook twice.
The condition is wrong: it tests whether resolved is running, but the
calls require the bus, not the daemon.
TWO FOLLOW-ON EFFECTS
1. The failure handler misdiagnoses:
# resolved was running, but without dbus, it means state files
# will not be read & resolvectl commands failed, restart it
if [ "$resolvectl_failed" ]; then
systemctl try-restart systemd-resolved
resolved is healthy; dbus is what is missing. The restart accomplishes
nothing and flushes the cache.
2. Ubuntu's [email protected] template runs both allow-classes:
ExecStart=/bin/sh -ec ifup --allow=hotplug %I; ifup --allow=auto %I;
...
so for an "auto" interface, ifup@<iface>.service and networking.service
both act on it and race for /run/network/ifstate.<iface>. The loser
blocks on the lock for the whole stall, hits TimeoutStartSec=5min,
ignores SIGTERM (blocked in lockf), and is SIGKILLed 90s later. The
visible symptom is "Failed to start networking.service - Raise network
interfaces", which points investigation away from the actual cause.
REPRODUCER
ifupdown installed, systemd-resolved enabled, and /etc/network/interfaces
containing a static stanza with dns-nameservers.
LOG (trimmed)
23:30:26.670 Started systemd-resolved.service
23:30:27.883 Started [email protected] - ifup for ens3.
23:30:27.886 Starting networking.service - Raise network interfaces...
23:30:27.956 ifup[784]: waiting for lock on /run/network/ifstate.ens3
23:31:58 sh[861]: Failed to get the global LLMNR support state:
Transport endpoint is not connected
23:33:28 sh[862]: Failed to get the global mDNS support state: ...
23:34:58 sh[863]: Failed to set domain configuration: ...
23:35:28.107 networking.service: start operation timed out. Terminating.
23:36:28 sh[864]: Failed to set DNS configuration: ...
23:36:28.287 Stopping systemd-resolved.service <- the hook's try-restart
23:36:57.577 networking.service: Killing process 784 (ifup) with SIGKILL
23:36:57.676 Starting dbus.service - D-Bus System Message Bus...
Note the last two lines: dbus starts in the same second networking.service
is finally killed. dbus was queued behind the unit that was blocked waiting
for dbus.
EXPECTED
The hook should not block boot when the system bus is unavailable. It
already writes /run/systemd/resolve/netif/$ifindex for the "resolved not
yet started" case, and resolved reads that on startup -- so the resolvectl
calls are an optimisation, not a requirement. Skipping them is harmless.
SUGGESTED FIX (any one)
- Gate on bus reachability rather than is-active, and fall back to the
state file otherwise.
- Wrap the resolvectl calls in "timeout 5".
- Order [email protected] and networking.service After=dbus.service.
- Drop or re-condition the try-restart fallback.
WORKAROUND
Remove dns-nameservers from /etc/network/interfaces and set DNS= in
/etc/systemd/resolved.conf.d/ instead. This empties the script's
[ "$DNS" ] || [ "$DNS6" ] guard, making the resolvectl block unreachable.
ProblemType: Bug
DistroRelease: Ubuntu 26.04
Package: systemd 259.5-0ubuntu3.3
ProcVersionSignature: Ubuntu 7.0.0-29.29-generic 7.0.12
Uname: Linux 7.0.0-29-generic x86_64
ApportVersion: 2.34.1-0ubuntu0.1
Architecture: amd64
CasperMD5CheckResult: unknown
Date: Fri Aug 7 00:07:18 2026
Lsusb:
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
Lsusb-t:
/: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid,
12M
MachineType: Red Hat KVM
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-256color
XDG_RUNTIME_DIR=<set>
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-7.0.0-29-generic
root=UUID=d582646e-0e5d-4d66-ac4f-dd42c07afcfe ro
crashkernel=2G-4G:320M,4G-32G:512M,32G-64G:1024M,64G-128G:2048M,128G-:4096M
SourcePackage: systemd
UpgradeStatus: Upgraded to resolute on 2026-08-06 (0 days ago)
dmi.bios.date: 04/01/2014
dmi.bios.release: 0.0
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.16.0-4.module_el8.9.0+3659+9c8643f3
dmi.chassis.type: 1
dmi.chassis.vendor: Red Hat
dmi.chassis.version: RHEL 7.6.0 PC (i440FX + PIIX, 1996)
dmi.modalias:
dmi:bvnSeaBIOS:bvr1.16.0-4.module_el8.9.0+3659+9c8643f3:bd04/01/2014:br0.0:svnRedHat:pnKVM:pvrRHEL7.6.0PC(i440FX+PIIX,1996):cvnRedHat:ct1:cvrRHEL7.6.0PC(i440FX+PIIX,1996):sku:pfaRedHatEnterpriseLinux:
dmi.product.family: Red Hat Enterprise Linux
dmi.product.name: KVM
dmi.product.version: RHEL 7.6.0 PC (i440FX + PIIX, 1996)
dmi.sys.vendor: Red Hat
** Affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug resolute
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162999
Title:
/etc/network/if-up.d/resolved blocks 90s per resolvectl call when
systemd-resolved is active before dbus.service, delaying boot by ~6
minutes
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/2162999/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
