Hello, Am Donnerstag, 25. April 2019, 22:19:15 CEST schrieb Olaf Hering:
Am Thu, 25 Apr 2019 20:01:39 +0000 schrieb Wayne Patton
: I would suggest: "systemctl disable systemd-resolved" That is working fine for me.
That was the obvious second step, once "rpm -e systemd-resolved" failed. But this fails because something else starts it on demand.
It's even more interesting than that - something *enabled* it :-/ On my system, I have lrwxrwxrwx 1 root root 48 15. Apr 14:13 /etc/systemd/system/dbus-org.freedesktop.resolve1.service -> /usr/lib/systemd/system/systemd-resolved.service I checked /var/log/zypp/history, and it only has entries for 2019-04-14 and 2019-04-16 (both zypper dup), which means something[tm] must have enabled systemd-resolved in a non-default way :-( To make things even more interesting - the next boot after the 2019-04-14 zypper dup was 2019-04-15 at 12:07, so systemd-resolved was enabled _two hours after booting_, and I have no idea why. For completeness: systemctl status systemd-resolved.service ● systemd-resolved.service - Network Name Resolution Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: disabled) so there's indeed no preset to enable it, which IMHO also means it shouldn't get enabled. Is there already a bugreport for this, or should I open one? Regards, Christian Boltz --
which camera is this? Marcus, this is my bug :) [Marcus Meissner and Stephan Kulow in https://bugzilla.novell.com/show_bug.cgi?id=217731]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org