GNOME Bugzilla – Bug 703040
NM shouldn't control MM's (0.8.x) lifecycle when using systemd
Last modified: 2015-04-12 11:14:24 UTC
When using systemd, NM should just listen for MM1 name-owner changes in DBus, and use MM only if available. This is, NM should neither explicitly ping MM to start it, nor try to restart it if it disappears from the bus.
Created attachment 258636 [details] [review] Patch.
This bug doesn't mention the symptom of this problem, but it's rather annoying, in Fedora 20: https://bugzilla.redhat.com/show_bug.cgi?id=1018017 if you have ModemManager disabled, you get four lines of spam in your system logs every two minutes, forever and ever. So it'd be nice if this bug could get fixed.
Comment on attachment 258636 [details] [review] Patch. ah, I was asking dcbw about this on IRC the other day. The general idea is fine, but NM already hardcodes systemd vs non-systemd at build time in several other places (NMSessionMonitor and NMSleepMonitor), so there's no need to check for systemd at runtime here. If NM is using systemd, then just assume that MM is too.
(In reply to comment #3) > (From update of attachment 258636 [details] [review]) > ah, I was asking dcbw about this on IRC the other day. > > The general idea is fine, but NM already hardcodes systemd vs non-systemd at > build time in several other places (NMSessionMonitor and NMSleepMonitor), so > there's no need to check for systemd at runtime here. If NM is using systemd, > then just assume that MM is too. Oh, that is much easier then :) I'll update the patch.
Created attachment 268044 [details] [review] Check for systemd at build time only Updated the patch so that if NM is built with systemd support, it won't try to poke MM to start it.
Comment on attachment 268044 [details] [review] Check for systemd at build time only looks right, assuming it's tested
Please use sd_booted() to determine whether systemd is PID 1. A static compile check is not sufficient for distros which still need to support sysvinit systems during the transition period. [1] http://www.freedesktop.org/software/systemd/man/sd_booted.html
as mentioned above, NM was already hardcoding systemd vs non-systemd in other things at build time. Bug 686997 has a patch to make the choice of session monitor happen at run time, and that can presumably be extended to cover the other uses of systemd as well.
Thanks for the hint, Dan. I've now subscribed to #686997
*** Bug 727783 has been marked as a duplicate of this bug. ***
I am still seeing: dbus[254]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.ModemManager1.service': Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or directory. In journalctl with ModemManager-1.4.4 and NM-1.0.0 (ModemManager.service is installed but not enabled at bootime). Is that normal? NetworkManager is built with systemd support: System paths: prefix: /usr exec_prefix: ${prefix} systemdunitdir: /usr/lib/systemd/system nmbinary: ${exec_prefix}/sbin/NetworkManager nmconfdir: /etc/NetworkManager nmdatadir: /usr/share/NetworkManager nmstatedir: /var/lib/NetworkManager nmrundir: /var/run/NetworkManager Platform: session tracking: systemd suspend/resume: systemd policykit: yes (restrictive modify.system) (default=yes) polkit agent: yes selinux: no Features: wext: yes wimax: no ppp: yes modemmanager-1: yes concheck: yes libteamdctl: no nmtui: yes Configuration plugins (main.plugins=keyfile) ibft: no ifcfg-rh: no ifcfg-suse: no ifupdown: no ifnet: no Handlers for /etc/resolv.conf: resolvconf: no netconfig: no DHCP clients: dhclient: /sbin/dhclient dhcpcd: no Miscellaneous: documentation: no tests: yes valgrind: no code coverage: no LTO: no