Bug 2305391

(In reply to Paul Wouters from comment #0)
> Running: sudo dnf remove systemd-resolved
> 
> - Does not stop the process that is running

That's not required by Packaging Guidelines and I'm not aware of any package that does it.

> - Does not cleanup NetworkManager / resolv.conf

It does, since https://pagure.io/systemd/c/27cc5e08c2c1880dba66ce46cabebfd17cac8fde (if I correctly understand what you mean).

> - Does not remove the "resolve" clause from /etc/nsswitch.conf

Rigthly so, because /etc/nsswitch.conf is managed by authselect.

root@thinkpad:/home/paul/fedora# systemctl  start xl2tpd.service
root@thinkpad:/home/paul/fedora# pidof xl2tpd
688304
root@thinkpad:/home/paul/fedora/# rpm -e xl2tpd
Removed '/etc/systemd/system/multi-user.target.wants/xl2tpd.service'.
warning: posix.fork(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.spawn() or rpm.execute() instead
warning: posix.wait(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.spawn() or rpm.execute() instead
warning: posix.exec(): .fork(), .exec(), .wait() and .redirect2null() are deprecated, use rpm.spawn() or rpm.execute() instead
root@thinkpad:/home/paul/fedora# pidof xl2tpd
root@thinkpad:/home/paul/fedora#

I just picked a random daemon here.

It does not cleanup, as I indicated you can see in the "steps to reproduce"

Also, if nsswitch is "managed" by authselect, the package should call authselect to remove the entry in nsswitch.conf.


What saddens me here is the lack of helping the enduser. If the enduser has needs that require a different DNS server, or something that works together with libvirtd and dnsmasq, then developers should not fight the enduser when they see a system is left with a broken DNS state. The information
retained in NM should be written to /etc/resolv.conf, no lame link to /run to a missing file should be left.


I wouldn't be filing bugs if I didn't get bitten by this.

rpm -e systemd-resolved should result in:
- NetworkManager reconfiguring /etc/resolv.conf now that the DNS provider has changed
- No more running systemd-resolved
- As glibc would still be trying to contact systemd-resolved before fallback, it should also remove the "resolve" keyword from nsswitch.conf

(In reply to Paul Wouters from comment #2)
> root@thinkpad:/home/paul/fedora# systemctl  start xl2tpd.service
> root@thinkpad:/home/paul/fedora# pidof xl2tpd
> 688304
> root@thinkpad:/home/paul/fedora/# rpm -e xl2tpd
> Removed '/etc/systemd/system/multi-user.target.wants/xl2tpd.service'.
> warning: posix.fork(): .fork(), .exec(), .wait() and .redirect2null() are
> deprecated, use rpm.spawn() or rpm.execute() instead
> warning: posix.wait(): .fork(), .exec(), .wait() and .redirect2null() are
> deprecated, use rpm.spawn() or rpm.execute() instead
> warning: posix.exec(): .fork(), .exec(), .wait() and .redirect2null() are
> deprecated, use rpm.spawn() or rpm.execute() instead
> root@thinkpad:/home/paul/fedora# pidof xl2tpd
> root@thinkpad:/home/paul/fedora#
> 
> I just picked a random daemon here.
> 
> It does not cleanup, as I indicated you can see in the "steps to reproduce"

You're right. If a package uses %systemd_preun macro in it's %preun script (as described by packaging guidelines these days), then listed unit files are both stopped and disabled. systemd-resolved hasn't been converted (yet) and directly calls `systemctl disable`. I'll fix that.

> 
> Also, if nsswitch is "managed" by authselect, the package should call
> authselect to remove the entry in nsswitch.conf.

Alas, "resolve" is unconditionally present in nsswitch.conf in all shipped authselect profiles. You can ask the authselect maintainers to conditionalize it, but I don't promise anything even if that happens. As I understand it, enablement of features (conditionals in authselect templates), just as selection of a profile, is admin territory, hence automation shouldn't touch that.

> 
> What saddens me here is the lack of helping the enduser. If the enduser has
> needs that require a different DNS server, or something that works together
> with libvirtd and dnsmasq, then developers should not fight the enduser when
> they see a system is left with a broken DNS state.

systemd-resolved is the default in Fedora. And it's (just) the default that's expected to be handled seamlessly (and is tested). Support for alternatives falls into the "nice to have" category. IOW, if you choose to diverge from the default, you're on your own territory and should expect that some manual steps might be needed. If you don't like that, remember that Fedora is open source: the obligatory response to a request like yours is "send a patch"...

The PR was merged. I backported the patch for f41 and f40 now.

FEDORA-2024-0e3d09ea81 (systemd-256.9-2.fc41) has been submitted as an update to Fedora 41.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-0e3d09ea81

FEDORA-2024-6d7608a5a6 (systemd-255.15-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d7608a5a6

FEDORA-2024-6d7608a5a6 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-6d7608a5a6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d7608a5a6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-0e3d09ea81 has been pushed to the Fedora 41 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-0e3d09ea81`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-0e3d09ea81

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-0e3d09ea81 (systemd-256.9-2.fc41) has been pushed to the Fedora 41 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-6d7608a5a6 (systemd-255.15-1.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.