root@Eternity ~ # /etc/init.d/sshd restart sshd | * WARNING: sshd is scheduled to start when NetworkManager has started root@Eternity ~ # /etc/init.d/NetworkManager start NetworkManager | * WARNING: NetworkManager has already started, but is inactive root@Eternity ~ # /etc/init.d/NetworkManager restart NetworkManager | * Stopping NetworkManager ... [ ok ] NetworkManager | * Starting NetworkManager ... [ ok ] NetworkManager | * WARNING: NetworkManager has started, but is inactive root@Eternity ~ # /etc/init.d/sshd restart sshd | * WARNING: sshd is scheduled to start when NetworkManager has started root@Eternity ~ # ps aux|grep NetworkManager root 16470 0.2 0.3 176880 7028 ? Ssl 23:09 0:00 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager.pid What exactly is the problem? My network connection works just fine (I use nm-applet) Other services depending on net cannot start (ssh, squid, etc) because of that. I am not sure if this is an openrc or a NetworkManager problem so CC'ing both
In networkmamanger-0.9.2.0-r3, /etc/init.d/NetworkManager provides net, but starts in "inactive" mode. It goes into "started" mode only after it brings up a network connection (and reverts to "inactive" when all connections managed by it are stopped). Therefore, when it goes into "started" mode, services that depend on net and that were scheduled to start after net became available should be started automatically in the background by openrc. This fixes a number of problems that people using networkmanager with openrc have experienced at system startup. Could you please clarify what is the problem that you are seeing? 1. Is the /etc/init.d/NetworkManager service still in "inactive" state even though nm is in the "connected" state? (check with nmcli nm) 2. Are services that need net failing to start after /etc/init.d/NetworkManager goes into the "started" state? (try the following: /etc/init.d/NetworkManager stop; /etc/init.d/sshd start; and after "/etc/init.d/NetworkManager status" shows "started", check that "/etc/init.d/sshd status" shows "started"). 3. Or is everything working correctly, but the messages printed by openrc when starting an inactive service are confusing?
(In reply to comment #1) > It goes into "started" mode only after it brings up > a network connection (and reverts to "inactive" when all connections managed by > it are stopped). I doubt that the part about *all* connections is true. I've just run into this issue when I wanted to manually start sshd - which failed with "scheduled to start after NetworkManager", which rc-status showed as "inactive" despite an active wifi connection managed by nm-applet. I then connected a VPN; rc-status showed "started". I then disconnected the VPN; rc-status showed "inactive" again. So, to me it seems as if /etc/NetworkManager/dispatch.d/10-openrc-status seems to set the service to "inactive" if *any* interface goes "down" or "vpn-down", not the last one. This is also with net-misc/networkmanager-0.9.2.0-r3 .
(In reply to comment #2) > I've just run into this issue when I wanted to manually start sshd - which > failed with "scheduled to start after NetworkManager", which rc-status showed > as "inactive" despite an active wifi connection managed by nm-applet. > > I then connected a VPN; rc-status showed "started". > I then disconnected the VPN; rc-status showed "inactive" again. rc-status shows the status of openrc runlevels; I assume you meant /etc/init.d/NetworkManager status. Please provide the output of "nmcli nm", "nmcli con", and "/etc/init.d/NetworkManager status" after you disconnect from vpn. > So, to me it seems as if /etc/NetworkManager/dispatch.d/10-openrc-status seems > to set the service to "inactive" if *any* interface goes "down" or "vpn-down", > not the last one. That should not be the case. Take a look at /etc/init.d/NetworkManager; when stop() called in background mode (e.g. by dispatch.d/10-openrc-status), the service goes inactive only if nmcli indicates that there is no connection.
[root@fireball] ~ # nmcli nm [0] RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabled enabled disabled [root@fireball] ~ # nmcli con [0] NAME UUID TYPE TIMESTAMP-REAL [ some outdated wlans deleted ] moloch2 b6a23cd2-2d96-190a-447d-39dbbdb77797 802-11-wireless Do 16 Feb 2012 16:06:24 CET Wired connection 1 02b4c1bc-c295-490a-b8f8-abde23a0b975 802-3-ethernet Do 16 Feb 2012 16:06:14 CET tubs 165fd416-b176-4a52-90c8-7b89ebee57a4 vpn Do 16 Feb 2012 16:08:42 CET [root@fireball] ~ # rc-status [0] Runlevel: default dbus [ started ] syslog-ng [ started ] consolekit [ started ] NetworkManager [ inactive ]
(In reply to comment #4) Thanks, this definitely shows that vpn-up/vpn-down dispatching is causing problems. But even if it worked perfectly, I now believe I had made a mistake by adding it: NetworkManager openrc service's status should simply correspond to whether nm is connected on any interfaces, irrespective of vpn activity. At the next networkmanager revbump, "up|vpn-up" and "down|vpn-down" will be changed to "up" and "down" in /etc/NetworkManager/dispatcher.d/10-openrc-status If you don't want to wait, you can make that change manually right now.
I have the same problem. I tried your fix and wanted to point out that is indeed working.
(In reply to comment #5) That still does not work. Consider my laptop in it's docking station, connected via wifi and wired LAN simultaneously. When I remove the computer from the dock, the wired connection shuts down but wireless is still connected and NM should not go inactive. The following seems to work: 24 # bug 402613 25 trackfile="/run/nm-connectiontracker" 26 [[ -a $trackfile ]] || touch $trackfile 27 28 if [[ "$2" == "up" ]] ; then 29 echo "$1" >> "$trackfile" 30 exec rc-service NetworkManager start 31 elif [[ "$2" == "down" ]] ; then 32 connections=`grep -v "$1" "$trackfile"` 33 echo "$connections" > "$trackfile" 34 if [[ -z "$connections" ]] ; then 35 exec rc-service NetworkManager stop 36 fi 37 fi
Thank you all for helping to diagnose this issue; it should be fixed in networkmanager-0.9.2.0-r4, which has a better init script and 10-openrc-status dispatcher. >*networkmanager-0.9.2.0-r4 (20 Feb 2012) > > 20 Feb 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +files/10-openrc-status-r1, +networkmanager-0.9.2.0-r4.ebuild, > +files/networkmanager-0.9.2.0-ifnet-password-truncated.patch, > +files/networkmanager-0.9.2.0-init-provide-net-r1.patch, > +files/networkmanager-0.9.2.0-pre-sleep.patch: > Fix openrc service going inactive while active connections are present (bug > #402613, thanks to Thomas Witt). Try to be more user-friendly by waiting a > few seconds before marking the service as inactive. Dispatch a pre-sleep > event to unmount network filesystems before suspending (bug #402085, thanks > to Marien Zwart). Do not truncate WPA passwords at '#' character (bug > #402133, thanks to John Hardin).
