Description of problem: Both pm-suspend and pm-hibernate seem to start, but then return to normal operation. Version-Release number of selected component (if applicable): pm-utils-1.4.1-18.fc17.i686 kernel-PAE-3.4.3-1.fc17.i686 kernel-PAE-3.4.4-3.fc17.i686 kernel-PAE-3.4.4-5.fc17.i686 How reproducible: Perfectly Steps to Reproduce: 1. Type pm-suspend 2. 3. Actual results: Network disconnects, then reconnects and laptop runs Expected results: Suspend to core Additional info: In BZ 819559 Jaroslav Škarvada told me to try these commands instead: Try suspend via: # echo mem > /sys/power/state and hibernate: # echo disk > /sys/power/state These work perfectly, and resume without issue. I now realize that these force operation NOW! without further ado. The pm-* method is much more "sophisticated", as revealed in /var/log/pm-suspend.log. Here are some relevant bits: ... Running hook /usr/lib/pm-utils/sleep.d/55NetworkManager hibernate hibernate: Having NetworkManager put all interfaces to sleep...Done. /usr/lib/pm-utils/sleep.d/55NetworkManager hibernate hibernate: success. Running hook /usr/lib/pm-utils/sleep.d/56dhclient hibernate hibernate: Device "DATIX0" does not exist. ./ifcfg-Tony's_Studio: line 11: unexpected EOF while looking for matching `"' ./ifcfg-Tony's_Studio: line 23: syntax error: unexpected end of file /usr/lib/pm-utils/sleep.d/56dhclient hibernate hibernate: Returned exit code 2. Mon Jul 9 12:14:34 EDT 2012: Inhibit found, will not perform hibernate ... pm-suspend checked a number of conditions and when it came to 56dhclient it barfed and gave up. Examining my /etc/systemconfig/network-scripts/ I can see a few anomalies, arguably errors inserted there by NetworkManager. It put DEVICE=DATIX0 into ifcfg-DATIX, which is nonsense. On a recent trip to Athens, I encountered a new wireless network which created a new file, ifcfg-Tony's_Studio. Evidently Tony doesn't know that <'> and < > are special characters, best avoided in network names. While NetworkManager seemed able to cope, pm-hibernate can't. The larger question is why should pm-hibernate be caring about what's in /etc/sysconfig/network-scripts at all, especially networks that in all likelihood will never be seen again? It should just shut the system down and hope for the best at wakeup. It should be the sole concern of whatever interface manager is in charge to wake up as best it can. It seems that pm-suspend and pm-hibernate are too smart for their own good.
> The larger question is why should pm-hibernate be caring about what's in > /etc/sysconfig/network-scripts at all, especially networks that in all > likelihood will never be seen again? It should just shut the system down > and hope for the best at wakeup. It should be the sole concern of whatever > interface manager is in charge to wake up as best it can. > The pm-utils allows other packages to provide their own suspend/resume hooks. Also this is the case - the 56dhclient is provided by dhcp client, not pm-utils itself (but do not reassign now, I will try to fix it here). AFAIK the purpose of this hook is to suspend/resume interfaces that are not under control of NetworkManager (feature for advanced users). To check whether the interface is under control of NM the scripts have to be sourced and it seems there is some escaping problem (probably in NAME or ESSID). It is also possible that the unescaped content was created by some older version of NetworkManager and persists there through updates. Could you provide the content of ifcfg-Tony's_Studio (or at least line 11)?
I will happily attach ifcfg-Tony's_Studio. In it you will confirm that there are unescaped content issues. That really isn't the point, though. I urge you to concentrate your mind on the UNIX principle, attributed to Doug McIlroy: "Write programs that do one thing and do it well." You should reevaluate the need or appropriateness for pm-suspend to stick its nose into issues that should be the sole province of NetworkManager. The task of NetworkManager is surprisingly complex because it must deal with events beyond its ability to control. It must be robust in the face of chaos. Some, but by no means all, of these events are signal interference, coming and going of radio links, unannounced suspend or hibernate, and yes, even misguided Athens hotel owners. Let us grant that the NetworkManager developers have done their job well. They seem to have handled the escaping of odd characters in the config files pretty well. pm-suspend should not be second-guessing them and trying to duplicate their work. If is found that NetworkManager cannot fully deal with some aspect of wakeup, then fix NetworkManger. Don't patch pm-suspend. Please consider ripping out all the second guessing and just convert pm-suspend into echo mem > /sys/power/state Is that too radical? Here's /etc/sysconfig/network-scripts/ifcfg-Tony's_Studio: $ cat "ifcfg-Tony's_Studio" ESSID='Tony\'s Studio' MODE=Managed TYPE=Wireless BOOTPROTO=dhcp DEFROUTE=yes IPV4_FAILURE_FATAL=no IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME="Tony\'s Studio" UUID=2bf7629f-8939-4dff-a89f-c2f934ad95dd ONBOOT=yes HWADDR=00:22:43:1B:ED:23 DEFAULTKEY=1 PEERDNS=yes PEERROUTES=yes IPV6_PEERDNS=yes IPV6_PEERROUTES=yes IPV6_PRIVACY=rfc3041 DEVICE=Tony's_Studio USERCTL=no
(In reply to comment #2) > I urge you to concentrate your mind on the UNIX principle, attributed to > Doug McIlroy: "Write programs that do one thing and do it well." You > should reevaluate the need or appropriateness for pm-suspend to stick its > nose into issues that should be the sole province of NetworkManager. > I disagree. NetworkManager is too complex and did not do one thing nor do them all well. To keep UNIX principles strictly in mind there are specific console tools (for LAN, WLAN, BT,...) that do it's job well (and they are also much more powerfull). There are users that don't like NetworkManager and you can't force them to use it. That'a all about Linux, options, freedom... From technical point of view, this is not pm-suspend, but dhcp package, that "stick its nose" there - the pm-suspend is only running its hook and the content of this hook is out of pm-suspend control. > Let us grant that the NetworkManager developers have done their job well. > They seem to have handled the escaping of odd characters in the config files > pretty well. > Apparently they didn't, look at ifcfg-Tony's_Studio. It is caled "network script" because it is script, so let's try: $ bash "/etc/sysconfig/network-scripts/ifcfg-Tony's_Studio" ifcfg-Tony's_Studio: line 11: unexpected EOF while looking for matching `"' ifcfg-Tony's_Studio: line 23: syntax error: unexpected end of file And that's the real problem here. > pm-suspend should not be second-guessing them and trying to > duplicate their work. > It didn't. The hook provided by dhcp package checks for interfaces not handled by NetworkManger and handles it itself. If it wouldn't be done this way then: a) Everybody would be forced to use NetworkManager for everything. I am pretty sure there are special cases that are not and would be hardly ever supported by NetworkManager. b) Interfaces not handled by NetworkManager wouldn't be suspended/resumed correctly. It doesn't touch NetworkManager controlled interfaces. > If is found that NetworkManager cannot fully deal with some aspect of wakeup, then fix NetworkManger. > Sometimes console is console, much more powerfull than some generic all purpose tools. Again I am pretty sure there are and always will be some special cases unsupported by NetworkManager. > Don't patch pm-suspend. > There is nothing to patch. > Please consider ripping out all the second guessing and just convert > pm-suspend into echo mem > /sys/power/state > > Is that too radical? > Yes it is. This is kernel call and it knows nothing about userspace needs. And the userspace also needs some cleanups to suspend/resume smoothly. That's a task of pm-utils. If you still think it shouldn't be done this way you can file a bug on dhcp package and request of 56dhclient hook removal, but in this case please also link my comment. Currently I am not able to reproduce this on my test system - NetworkManager creates there correctly escaped scripts, so this bug was probably fixed by some of previous NetworkManger updates and the incorrectly escaped script persists on your system between updates. That's why I am closing this as notabug.
pm-suspend now works for me because, as an experiment, I removed the badly constructed files in /etc/sysconfig/network-scripts/ - ifcfg-Tony's_Studio and keys-Tony's_Studio - by using the nm-applet edit feature and deleting that network. (I did save the offending files for future reference.) With these offending files absent, pm-suspend works. So my residual question is: Who do we tag to fix this? NetworkManager - for creating poorly constructed files? 56dhclient - for being unable to parse the poorly constructed files? pm-utils - for unnecessarily invoking 56dhclient? Or should I write a nice letter to Tony in Athens informing him his network name conflicts with Fedora 17 standards? :-)