Comment 28 for bug 1337200

My branch that disconnects from the signals on suspend and connect again on resume doesn't really fix this. I did make the system-settings code more efficient, but actually it doesn't connect to device-changed signals. Only device-added and device-removed. There are some places where we call some synchronous functions on upower, and when dbus-daemon is busy caused blocking issues.

I did some more testing tonight and found that even without system-settings running when the device sleeps, dbus-daemon uses quite a bit of CPU on resume. I saw between 24% and 87% without system-settings even running and would last for anywhere from 10s to over a minute. Attempting to start system-settings while dbus-daemon was busy would cause dbus-daemon load go up quite a bit and last longer. When dbus-daemon was the top culprit for the high load, upowerd was a distant #2, at just over 1%. However, once dbus-daemon settled down, upowerd would drop back to 0%.

My new theory is dbus-daemon is spinning out of control because of upower, probably because indicator-power is still subscribed to it. When the device wakes, upowerd must be flooding dbus itself. When dbus-daemon is busy, it blocks or is just slow to respond.

Another observation, I think this situation is more noticeable when the device is plugged into a computer, not just a wall charger. I didn't check the load on resume while plugged into a wall charger, but system-settings UI was much more responsive on waking up.