In a fresh cauldron install, NM fails to start with the message: "bus manager: could not acquire the NetworkManager service as it is already taken" "failed to start the dbus service"
Assignee: bugsquad => gnomeCC: (none) => marja11
This has been fixed in the last day or two. Both NM and dbus were updated.
Status: NEW => RESOLVEDResolution: (none) => FIXED
My mistake. I got it to start manually, but upon reboot the error reoccurred: Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0466] NetworkManager (version 1.6.2) is starting... Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0466] Read config: /etc/NetworkManager/NetworkManager.conf Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0486] manager[0x2484080]: monitoring kernel firmware directory '/lib/firmware'. Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0495] dns-mgr[0x2478180]: init: dns=default, rc-manager=resolvconf Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0504] rfkill1: found WiFi radio killswitch (at /sys/devices/pci0000:00/0000:00:1c.6/0000:02:00.0/ieee80211/phy0/rfkill1) (driver iwlwifi) Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0505] rfkill2: found WiFi radio killswitch (at /sys/devices/platform/asus-nb-wmi/rfkill/rfkill2) (platform driver asus-nb-wmi) Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0509] manager[0x2484080]: WiFi hardware radio set enabled Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.0509] manager[0x2484080]: WWAN hardware radio set enabled Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <error> [1487524318.0514] bus-manager: could not acquire the NetworkManager service as it is already taken Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <error> [1487524318.0514] failed to start the dbus service. Feb 19 12:11:58 localhost.localdomain NetworkManager[2945]: <info> [1487524318.1485] exiting (error) Feb 19 12:11:58 localhost.localdomain systemd[1]: NetworkManager.service: Main process exited, code=exited, status=1/FAILURE Feb 19 12:11:58 localhost.localdomain systemd[1]: Failed to start Network Manager. Feb 19 12:11:58 localhost.localdomain systemd[1]: NetworkManager.service: Unit entered failed state.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
ARGGH. The problem here is that someone slipped in a new package called connmgr which uses the same dbus assignments as NM and installs it by default. Install and enable them both, and it's a race to see who gets there first. I've no idea what whoever's responsible for this wants to do about it.
Source RPM: networkmanager => connmgr
The following is for sure problematic. Not sure if there's more: /etc/dbus-1/system.d/connman-nmcompat.conf I've made NM conflict with connman. Noticed Fedora doesn't ship above file.
CC: (none) => olav
Assignee: gnome => shlomif
Source RPM: connmgr => connman
$ mgarepo maintdb get connman shlomif Reassigning to connman maintainer. Feel free to change anything including NM (should be needless to say but rather be clear).
connman isn't enabled anymore by default after install. I also added README.urpmi to connman to explain that no more than one network manager should be enabled at the same time. I also removed connman conflicts from networkmanager to able to install/test both pkgs without first removing other.
CC: (none) => jani.valimaa
Maybe we could add conflicts to systemd unit files. From https://www.freedesktop.org/software/systemd/man/systemd.unit.html Conflicts= A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= setting on another unit, starting the former will stop the latter and vice versa. Note that this setting is independent of and orthogonal to the After= and Before= ordering dependencies. If a unit A that conflicts with a unit B is scheduled to be started at the same time as B, the transaction will either fail (in case both are required part of the transaction) or be modified to be fixed (in case one or both jobs are not a required part of the transaction). In the latter case, the job that is not the required will be removed, or in case both are not required, the unit that conflicts will be started and the unit that is conflicted is stopped.
That shows promise, but is the stopped service stopped quietly or does it enter an error state ? If both A and B somehow get enabled, and the user expects B but A wins the toss, the user is going to be very confused to find simply that B is stopped with no indication of why.
It's something that someone should check.
Put in your change, and I'll try it.
Just edit /usr/lib/systemd/system/connman.service and add 'networkmanager.service' (without quotes) to Conflicts= line. Use space as separator between entries.
Closing. I've done several fresh installs since, and not had a problem.
Resolution: (none) => FIXEDStatus: REOPENED => RESOLVED