Todd Zullinger writes:
Kevin Fenzi wrote: [...snip loads of useful information...]
So, I think if you:
disable systemd-resolved
To that end, the change proposal¹ when systemd-resolved was enabled by default (F33) contains an example of how to ensure the service remains disabled -- which would avoid the situation Sam had where it got installed due to a dependency chain and then started because the preset enables it.
Well, if it was installed due to a dependency, then it would be reasonably expected that whatever declared it as a dependency required a working systemd-resolved. After all, why declare it as a dependency, otherwise?
sudo bash -c 'mkdir -p /etc/systemd/system-preset && echo "disable systemd- resolved.service" >/etc/systemd/system-preset/20-systemd-resolved- disable.preset'
I used that at the time and have not had systemd-resolved start up on any updates or upgrades (so far and IIRC).
And doing that would presumably break whatever pulled in systemd-resolved, due to a bone-fide dependency on a working systemd-resolved.
So, either something needed systemd-resolved, or not. If it did not really need it, it should not've been declared as a dependency. If it did, then a preset that disables systemd-resolved would break something.
This whole preset mechanism seems like a workaround for a functional or a design gap.