Package: systemd
Version: 251.3-2~exp1
Severity: critical
(filing the bug as critical since it "makes unrelated software on the
system (or the whole system) break", feel free to downgrade)
Dear developers,
A recent update of systemd splits systemd-resolved in its own package,
and the new systemd-resolved is not installed by default, thus, during
the upgrade, the systemd-resolved service is stopped and removed (which
seems to be the intended behavior).
In the (admittedly probably rare) case where systemd-resolved's stub
resolver was already in use beforehand (meaning, /etc/resolv.conf was
already symlinked to /run/systemd/resolve/stub-resolv.conf), the upgrade
completely breaks DNS resolution, since the file (which remains in
/run/systemd/resolve) lists 127.0.0.53 as the only nameserver, which
doesn't respond anymore since the systemd-resolved service was stopped.
The breakage lasts until the user manually fixes it by installing
systemd-resolved, but this simple operation may be tricky, because
there's no DNS resolution anymore and apt will fail to download the new
package, unless the user manually creates a temporary /etc/resolv.conf
file listing a working name server, or symlinks /etc/resolv.conf to
/run/systemd/resolve/resolv.conf instead (which also remains in /run
after the service is stopped, and doesn't use the stub resolver since
this file, unlike stub-resolv.conf, lists the upstream name servers).
One possible solution would be to check in the maintainer scripts if the
stub resolver is already in use (in other terms, if /etc/resolv.conf is
a symlink to /run/systemd/resolve/stub-resolv.conf), and, if it's the
case, do what's described above (symlink /etc/resolv.conf to
/run/systemd/resolve/resolv.conf instead, thus bypassing the stub
resolver). This would keep DNS resolution working (until the next
reboot, that is), but the user will at least have the time to read the
NEWS entry, and act accordingly.
Regards,
--
Raphaël Halimi
