After suspend2ram Networkmanager restarts the connections but stays "inactive" so privoxy won't restart. Reproducible: Always Steps to Reproduce: 1. connect to wlan/lan 2. s2ram 3. resume Actual Results: NM connects, but is inactive Expected Results: NM should connect and go active, start privoxy might be related to bug #402613
There is no networkmanager-0.9.2.4; am I correct in assuming you are talking about 0.9.4.0? The openrc NetworkManager service marks itself as "inactive" at startup if it can't establish a connection within INACTIVE_TIMEOUT seconds (see /etc/conf.d/NetworkManager), but it should automatically get marked as "started" by a dispatcher event as soon as at least one connection becomes established. So in theory, the networkmanager daemon's real status and the openrc NetworkManager service status should always match. If they don't, there is a bug somewhere. Please verify whether this is happening by giving the output of the following commands: nmcli nm nmcli dev /etc/init.d/NetworkManager status
yes, it is 0.9.4.0. I'm sorry. [pyro@fireball] ~ % nmcli nm [0] RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabled enabled enabled [pyro@fireball] ~ % nmcli dev [0] DEVICE TYPE STATE wlan0 802-11-wireless connected eth0 802-3-ethernet unavailable [pyro@fireball] ~ % /etc/init.d/NetworkManager status [0] * status: inactive [pyro@fireball] ~ % [16] This problem is *not* reproducable while connected to wired LAN. Only WLAN is affected.
Confirmed. It appears that networkmanager-0.9.4.0 is sometimes dispatching pre-sleep events only after resuming from suspend and establishing a connection, instead of before suspending :/
(In reply to comment #3) After debugging this a bit further, the real cause appears to be that networkmanager-0.9.4.0 simply fails to dispatch "up" events for wireless connections when waking up from sleep. Upstream bug filed at https://bugzilla.gnome.org/show_bug.cgi?id=673682
Hi, I am having the exactly same problems with my wired LAN after resume from s2ram. (NM 0.9.4.0-r2). SO it seems not only be realted to WLAN. I have manually disabled my WLAN connection, just to mention. After restarting /etc/init.d/NetworkManager it changes from inactive to active. After restarting: bart ~ # nmcli nm RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled disabled enabled disabled bart ~ # nmcli dev DEVICE TYPE STATE wlan0 802-11-wireless unavailable eth0 802-3-ethernet connected bart ~ #
Is there any update on this? This is quite annoying, and the stable NM freezes my entire system about twice per day. As upstream is obviously not interested, can you remove the entire inactivity-initscript handling?
I am having the same issue here, is quite annoying. Therefore, I cannot start Apache because of this: /etc/init.d/apache2 start * WARNING: netmount is scheduled to start when NetworkManager has started * WARNING: apache2 is scheduled to start when NetworkManager has started /etc/init.d/apache2 status * status: stopped nmcli nm RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabled enabled enabled nmcli dev DEVICE TYPE STATE eth1 802-11-wireless connected eth0 802-3-ethernet unavailable /etc/init.d/NetworkManager status * status: inactive Gentoo ~AMD64 Network Driver: Broadcom Corporation BCM4313
Raising severity because this issue affects every initscript depending on net. Please fix asap.
I have the same problem, and cannot start any service which depends on net. It also fails to start them from boot, regardless of suspending. Atlantis ~ # nmcli nm RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN running connected enabled enabled enabled enabled Atlantis ~ # nmcli dev DEVICE TYPE STATE wlan0 802-11-wireless connected eth0 802-3-ethernet unavailable Atlantis ~ # /etc/init.d/NetworkManager status * status: inactive Atlantis ~ #
PS, but setting INACTIVE_TIMEOUT high, I'm able to boot properly.
After two months of inactivity on the upstream bug, could someone please remove this "active-inactive" stuff (or remove NM from portage completely) or in some other way just unbreak all the initscripts depending on net?
I'm seeing also similar issue with wired connections.
After many hours digging through code and trying to figure out the issue here I believe I've found it. I have limited resources to test with however it has worked flawlessly for me since my little patch. I noticed after much trial that our openrc dispatcher script would hang. Running ps aux | grep dispatch would produce something like this: root 16320 0.0 0.0 20140 1640 ? S 00:41 0:00 /bin/sh /etc/NetworkManager/dispatcher.d/10-openrc-status wlan0 down long after the event had occurred. My guess is nm queues the dispatcher execs up and because of the hang a following trigger would exec the next script on the queue throwing it all off. I made my own little test script and 'down' was getting called every time upon resume instead of 'up'. In any case I'm not much of a coder but I hope this helps. My small change was to edit /etc/NetworkManager/dispatcher.d/10-openrc-status and add the -x option to all the nm-online calls. up) nm-online -t 0 -x && exec rc-service NetworkManager start ;; down) nm-online -t 0 -x || exec rc-service NetworkManager stop ;; As I said my testing is obviously limited but it's been working flawless for me. Does this work for anyone else? If so can I please get gnome-shell-3.4? :)
(In reply to comment #13) Travis Hansen, you should be a gentoo gnome team member! Your solution is correct. >*networkmanager-0.9.4.0-r4 (05 Jul 2012) > > 05 Jul 2012; Alexandre Rostovtsev <tetromino@gentoo.org> > +files/10-openrc-status-r2, -networkmanager-0.9.4.0-r3.ebuild, > +networkmanager-0.9.4.0-r4.ebuild, > +files/networkmanager-0.9.4.0-dhclient-ipv6.patch: > Fix the hang in 10-openrc-status that resulted in networkmanager getting > marked as 'inactive' on resuming from suspend; many thanks to Travis Hansen > for the solution (bugs #410661, #417283). Fix incompatibility with > net-misc/dhcp[-ipv6] (bug #335147, thanks to Rick Harris). Move polkit > rules.d file to /usr/share (bug #421577 comment #12, thanks to Dennis > Lissov).
*** Bug 417283 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > After many hours digging through code and trying to figure out the issue > here I believe I've found it. I have limited resources to test with however > it has worked flawlessly for me since my little patch. > > I noticed after much trial that our openrc dispatcher script would hang. > Running ps aux | grep dispatch would produce something like this: > > root 16320 0.0 0.0 20140 1640 ? S 00:41 0:00 /bin/sh > /etc/NetworkManager/dispatcher.d/10-openrc-status wlan0 down > > long after the event had occurred. My guess is nm queues the dispatcher > execs up and because of the hang a following trigger would exec the next > script on the queue throwing it all off. I made my own little test script > and 'down' was getting called every time upon resume instead of 'up'. > > In any case I'm not much of a coder but I hope this helps. My small change > was to edit /etc/NetworkManager/dispatcher.d/10-openrc-status and add the -x > option to all the nm-online calls. > > up) nm-online -t 0 -x && exec rc-service NetworkManager start ;; > down) nm-online -t 0 -x || exec rc-service NetworkManager stop ;; > > As I said my testing is obviously limited but it's been working flawless for > me. Does this work for anyone else? If so can I please get > gnome-shell-3.4? :) Hello Travis Hansen, Thank you for providing the solution to this issue, I've changed the lines on my settings and seems to be working good. Regards
