Justin Moore writes:
This kind of blanket dismissal of user feedback and refusal to
believe *even
the possibility* that systemd could be broken in obvious ways contributes to
the sense from the community that negative feedback about systemd has been
and will be ignored.
Had the response been "What kind of system was it? What test cases did you
do? Which time frames?" then at least it would come across as a constructive
attempt to solve the problem. But a blanket dismissal of the possibility that
systemd could fail to exit cleanly as opposed to admitting that maybe they
were bit by any of the previous bugs where systemd would crash on exit [1, 2,
3, 4] reinforces the sense of "systemd advocates don't listen to user
feedback".
And in the instant case, we had:
1) A broken systemd-resolved scriptlet that ended up overwriting the
/etc/resolv.conf symlink. This was fixed in the -2 update, but the initial
reports were ignored, because we were told that the symlink gets created
only on the initial install, and not an upgrade. Well, it turns out this
wasn't the case.
2) Completely unaddressed was the reason all of that came to light: either
the original update also broke DNS resolution on the LAN, or it was always
broken and systemd-resolved never adds the DHCP-provided domain to the
"search" directory in its /etc/resolv.conf, but NetworkManager always does
that. I documented that.
I don't know if the -2 update fixes this or not. But that's another bug that
at least was initially ignored. From all the looks it's still being ignored.
The only reason systemd-resolved exists is because glibc caches
/etc/resolv.conf when a process performs its first DNS lookup. Having the
means to have an existing process become aware that its been changed, and it
should reread it, will completely eliminate the reason for systemd-
resolved's existence. That, I think, is the right solution, and it was
always the right solution.