Bug 10466

Well, now it looks as if this solution -- enabling "NetworkManager-wait-online.service -- isn't working.  It works when I only sleep for a few minutes, but if I let the computer sleep for more than that, the wifi only comes up if I close the lid and open it a two or three times. 

Frustrating.  

I'm suspecting that perhaps I have conflicting network services enabled, but I can't figure out which they might be.

Question:  Some Mageia bug reports 

https://bugs.mageia.org/show_bug.cgi?id=6675
https://bugs.mageia.org/show_bug.cgi?id=7317


suggest a conflict between networkmanager (required by Gnome?) and drakx-net (installed by Mageia always). 

Is it possible to uninstall drakx-net, drakx-net-applet, and the associated libraries, and only use networkmanager and networkmanager-applet (and also the related knetworkmanager packages in KDE)? 

Would there be a correct order for uninstalling?  For example, should I uninstall networkmanager and related packages first, then uninstall drakx-net packages, then reinstall networkmanager packages and re-configure my wireless network connections?  Do I need to delete anything in /etc/sysconfig/network/ to start "clean"? 

I am happy to test a procedure to see if it brings stability to my networking.  At the moment, systemctl seems to suggest I have some conflicts and failures: 

[root@localhost andy]# systemctl list-units | grep -i net
sys-devi...et-eth0.device loaded active plugged       NetXtreme BCM57765 Gigabit Ethernet PCIe
sys-devi...-vmnet1.device loaded active plugged       /sys/devices/virtual/net/vmnet1
sys-devi...-vmnet8.device loaded active plugged       /sys/devices/virtual/net/vmnet8
sys-subs...es-eth0.device loaded active plugged       NetXtreme BCM57765 Gigabit Ethernet PCIe
sys-subs...-vmnet1.device loaded active plugged       /sys/subsystem/net/devices/vmnet1
sys-subs...-vmnet8.device loaded active plugged       /sys/subsystem/net/devices/vmnet8
network-up.service        loaded active exited        LSB: Wait for the hotplugged network to be up
network.service           loaded failed failed        LSB: Bring up/down networking
NetworkManager.service    loaded active running       Network Manager
ntpd.service              loaded active running       Network Time Service
network.target            loaded active active        Network
nss-lookup.target         loaded active active        Host and Network Name Lookups
openvpn.target            loaded active active        OpenVPN Networks

For what it's worth, I seem to have a solution to the problem. Id I run

     systemctl suspend

on the command line, when I wake up my laptop again, the network is always working.  I have now suspended it and woken it up about 30 times in the past 24 hours -- once for 9 hours, once for 2 hours, once for 45 minutes -- the rest of the times were "tests" of only a few minutes.  But it has not yet failed once. 

I am curious.  What actually happens in Gnome (and also in KDE) when you close the lid of a laptop? Or when you click on "Suspend" in a shutdown menu. It doesn't seem that "systemctl suspend" is actually getting called. It seems like it's some "dbus" thing. 

And now more information: 

If I run on the command line, 
"gnome-screensaver-command -l; sudo systemctl suspend"

my laptop seems to behave exactly as it does when I close the lid.  The screen gets locked, the system suspends, and when I wake up the computer again, the network (wifi and/or wired) is ALWAYS working

Is there not a way to run this command as a script that is called by an icon? I installed an extension to Gnome (QuickLaunch) that allows me to make icons in a drop down menu that call commands or scripts.  I am able to call "sudo systemctl suspend" (a command I have added to /etc/sudoers) but I am unable to call the command with "gnome-screensaver" or even a script that includes both. 

I'm sort of stumped, but hopeful that there is a solution that can help not only me but others who seem to have this issue.

Sorry, I had a stupid typo in my very simple shell script that locks the screen and suspends the laptop. That's why it wasn't working.  So, I am satisfied I have a good solution to my problem. 

I have made a shell script that locks the screen and suspends the laptop: 

#!/bin/sh
gnome-screensaver-command -l
sleep 1
sudo systemctl suspend

I call that script from a Quicklaunch extension item called "Suspend".  After the laptop suspends, I am able to close the laptop screen and the laptop stays suspended. No waking up in my laptop bag like it did constantly when running Kubuntu 13.04 (that's why I switched back to Mageia.  A hot laptop is dangerous).  When I open the laptop screen again, my laptop resumes with a prompt for the password and my wireless ALWAYS comes back immediately.  It hasn't failed yet in almost two days. 

Now, why can't the normal Gnome and KDE suspend actions do the exact same thing as my script? And why can't closing the lid trigger this same script?

Status: NEW => RESOLVED
Resolution: (none) => WORKSFORME

FWIW, if you are the current active user, you should be able to suspend your laptop with just "systemctl suspend" and not need the sudo bit.

That said, closing the lid should just be ultimately handled by systemctl anyway. It does go via some upower stuff, but that's where it should end up. This is all triggerd over dbus.

It would be nice to be able to get to the bottom of why simply closing the lid doesn't work for you (it does here for me on my laptop) but it's a tricky process to debug...

Thanks for the tip about not needing sudo. 

I don't think this is a Mageia problem.  One of my colleagues told me yesterday he has this same problem with his desktop computer when he suspends.  He is running Debian Unstable with just Gnome 3.8 and after suspend, about 2/3rd of the time he needs to turn his WIFI off and back on again to get it to work. He is running the same OS on his Lenovo laptop and does not have the problem. 

I have also seen many posts from people running Fedora, Arch and Suse, who report the same problem I have with my laptop. Some seem to suggest that the latest versions of networkmanager may resolve the problem, but others say updating networkmanager did not fix it for them.  

Anyway, WIFI not coming back after resume is one of those very annoying things.  It should "just work" without a lot of fuss. I'm happy to get some logs for you if you want to troubleshoot.  I can still reproduce the problem if I just close the lid and open it again about 10 seconds later.  I already did some troubleshooting by running a few terminal windows during suspend and resume. 

journalctl --follow
watch -n 1 "ps aux | grep wpa"
watch -n 1 "lsmod | grep b43" 

Some people have suggested the problem is that you can get two instances of wpa_supplicant, but I have not seen that.  What I have seen is that when the WIFI does not come back, there is very little in the output of journalctl after resume. But that may just be a symptom and not point to any cause.  I didn't see anything in the logs that might explain what's going on.

One more thing to mention.  Before installing Mageia 3, I tried out the Mageia 3 Live DVD for a few days (I tested both Gnome and KDE).  While running those versions, I suspended and resumed many times by closing the laptop lid.  In fact, a few days ago I went back to the Live Gnome DVD for about 24 hours and it didn't give me any problems with suspend and resume.  The network always came back with a lid close and lid open.  

Also, one other clue. After the full install, when I was resuming after a suspend and I had to turn the WIFI off and on to get my connection back,  after reconnecting I would only see the one SSID that I was currently connected to.  I wasn't seeing the whole list of all SSIDs detected around me.  Now that I am suspending with "systemctl suspend", when I resume I always instantly see the WIFI SSIDs where I am located.  I just had this experience this morning. I was at home where there are about 20 SSIDs that I can see strongly near my house.  I supended.  I got into work and instantly I could see the list of the 10 SSIDs near my office.