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.
Attachment:
pgppjwFNpc7iv.pgp
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
