Bug 56501 - systemd support incomplete: pm-is-supported still called
Summary: systemd support incomplete: pm-is-supported still called
Status: RESOLVED FIXED
Alias: None
Product: upower
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Richard Hughes
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-28 18:17 UTC by Colin Guthrie
Modified: 2013-02-19 16:05 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Very simple patch that at least allows pm-utils to be removed (3.40 KB, text/plain)
2012-12-06 12:06 UTC, Colin Guthrie
Details
Don't run the powersave functions under systemd (1.09 KB, text/plain)
2012-12-06 12:07 UTC, Colin Guthrie
Details

Description Colin Guthrie 2012-10-28 18:17:03 UTC
Related to #51305, the function up_backend_supports_sleep_state() still calls the legacy "pm-is-supported --[suspend|hibernate]" command. This causes UI issues in at least KDE and also in Gnome last time I looked (I no longer have the option to suspend in the menu after removing pm-utils).

While the "correct" solution is to simply deprecate these properties and update client code to use the logind APIs directly, if they are exposed they should likely be either hardcoded to false under systemd (i.e. never all pm-is-supported when sd_booted()) or act as a proxy to the result of:

gdbus call --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend

(if it contains 'yes' or 'challenge' then all is well)


So a simple "hack" to just call the above gdbus and parse the result in up-backend.c won't work as the upower daemon user != the client user. It would need to be run as the user in question to get the right result.

It could be hacked up in the glib client wrapper, but that's not really a proper solution.

What's the best way to do this?


As a related note, there is also a call up_backend_get_powersave_command() which also uses a pm-* utility even under systemd. Lennart reckons there is no real equiv of this under systemd (power saving stuff should always be active) and thus that should at very least be no-op'ed to mask any pm-* calls.
Comment 1 Colin Guthrie 2012-10-28 18:19:06 UTC
Incidentally, credit to Luc Menut via the Mageia mailing list for poking at the source to uncover this.
Comment 2 Colin Guthrie 2012-12-06 12:06:06 UTC
Created attachment 71083 [details]
Very simple patch that at least allows pm-utils to be removed

This patch is arguably hacky, but it's just a demonstration of how things could work (and it works for me) to avoid the situation we are in now in Gnome in that if pm-utils is removed, the suspend option will not be shown as an option in the menu.

Obviously the correct solution is simply to not call this function any longer and rely directly on logind calls (which are properly contextual in terms of which user is requesting the info), so this should really be considered a sticking plaster rather than anything proper.

A better solution would be to not rely on grep etc., but I'm lazy :)
Comment 3 Colin Guthrie 2012-12-06 12:07:28 UTC
Created attachment 71084 [details]
Don't run the powersave functions under systemd

This one is a bit more intrusive. It will not run pm-powersave at all when booted under systemd. Some users may actually wish this still to be done, so you may or may not want to do this.

Lennart's argument previously was that powersaving should be an always-on kinda thing, not a "only when on battery" kinda thing. Not sure everyone will buy that.
Comment 4 Richard Hughes 2013-02-19 16:05:08 UTC
Fixed by ripping out all the deprecated bits.


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.