Created attachment 56684 [details] [review]
patch to drop the parameter
As reported downstream at https://bugzilla.redhat.com/show_bug.cgi?id=740342, the use of --print-reply in /usr/lib64/pm-utils/sleep.d/95packagekit seems to be the key culprit in the Case Of The Mysterious Delay on resume-from-suspend on at least my machine and probably others. sleep.d scripts are run in reverse order on resume from suspend, so 95packagekit happens before almost anything else, including the 55NetworkManager script which should wake up the network. The use of --print-reply in the the dbus-send command in 95packagekit means the command won't return immediately and allow dbus to work away on it in the background, allowing the rest of the resume process to continue immediately; it makes the command block until it actually gets a reply from dbus. In my case, quite often when I wake from suspend, the dbus send actually fails, and this means I have to wait 25 seconds for it to time out before the dbus-send command returns and the rest of the resume process (including bringing up the network again) is completed.
In my tests, removing the --print-reply parameter results in the rest of the resume process (including network resume) happening immediately, and actually ends up with the dbus send succeeding (I think once the network is up), so this change both eliminates the annoying 25 second delay *and* makes the PackageKit wakeup more reliable. A plan with no drawbacks!
Attaching a patch which simply drops the --print-reply. As a side note, I'm not sure 95 is an appropriate ordering for the packagekit snippet anyway. It doesn't seem to make any sense for 'refresh PK caches' to be one of the very last thing that happens on suspend - after the network is taken down - and one of the very first things that happens on resume - before the network comes back up...
Pushed to master. Thanks!
Thanks a lot!
Did you see the full IRC discussion, though? Ray (I think it was Ray...) was worried that this isn't the correct fix, and using dbus-send without --print-reply is fragile. I haven't had any problems with it, but it's obviously worth taking into account.
He asked lots of sensible questions about whether this snippet needs to exist at all, and whether we should look into why the dbus-send request is actually failing. It's probably worth taking a look through the log to see if there's a better way to approach this. I'm not the sharpest knife in this drawer. =)