After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 703040 - NM shouldn't control MM's (0.8.x) lifecycle when using systemd
NM shouldn't control MM's (0.8.x) lifecycle when using systemd
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: Mobile broadband
0.9.x
Other Linux
: Normal enhancement
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
: 727783 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-06-25 10:06 UTC by Aleksander Morgado
Modified: 2015-04-12 11:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch. (5.06 KB, patch)
2013-10-31 08:43 UTC, Aleksander Morgado
needs-work Details | Review
Check for systemd at build time only (6.22 KB, patch)
2014-02-04 09:37 UTC, Aleksander Morgado
committed Details | Review

Description Aleksander Morgado 2013-06-25 10:06:45 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.
Comment 1 Aleksander Morgado 2013-10-31 08:43:38 UTC
Created attachment 258636 [details] [review]
Patch.
Comment 2 Adam Williamson 2013-12-14 18:18:26 UTC
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 3 Dan Winship 2013-12-23 21:41:56 UTC
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.
Comment 4 Aleksander Morgado 2014-01-29 19:51:13 UTC
(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.
Comment 5 Aleksander Morgado 2014-02-04 09:37:55 UTC
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 6 Dan Winship 2014-02-13 16:04:39 UTC
Comment on attachment 268044 [details] [review]
Check for systemd at build time only

looks right, assuming it's tested
Comment 7 Michael Biebl 2014-04-02 21:42:41 UTC
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
Comment 8 Dan Winship 2014-04-03 12:02:43 UTC
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.
Comment 9 Michael Biebl 2014-04-04 12:35:52 UTC
Thanks for the hint, Dan.
I've now subscribed to #686997
Comment 10 Aleksander Morgado 2014-04-08 09:42:59 UTC
*** Bug 727783 has been marked as a duplicate of this bug. ***
Comment 11 Pacho Ramos 2015-04-12 11:14:24 UTC
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