Bug 45710 - Use of --print-reply in /usr/lib64/pm-utils/sleep.d/95packagekit causes it to block subsequent pm-utils hooks on wake
Summary: Use of --print-reply in /usr/lib64/pm-utils/sleep.d/95packagekit causes it to...
Status: RESOLVED FIXED
Alias: None
Product: PackageKit
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All All
: medium major
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-06 11:01 UTC by Adam Williamson
Modified: 2012-03-16 13:50 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
patch to drop the parameter (1.42 KB, patch)
2012-02-06 11:01 UTC, Adam Williamson 		Details | Splinter Review
View All

Description Adam Williamson 2012-02-06 11:01:47 UTC 
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...
Comment 1 Richard Hughes 2012-03-16 13:19:24 UTC 
Pushed to master. Thanks!
Comment 2 Adam Williamson 2012-03-16 13:50:56 UTC 
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. =)

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.