Bug 85518

Summary:	Closing lid with multiple sessions open fails with an polkit authentication session on the inactive session
Product:	systemd	Reporter:	Didier 'OdyX' Raboud <odyx>
Component:	general	Assignee:	systemd-bugs
Status:	RESOLVED NOTOURBUG	QA Contact:	systemd-bugs
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Didier 'OdyX' Raboud 2014-10-27 14:56:06 UTC

Hi,

here's my use-case: I routinely have two KDE sessions open and want my laptop lid closure to always suspend the (X220 Thinkpad) laptop. According to /usr/share/polkit-1/actions/org.freedesktop.login1.policy , this is what
should happen.

Besides, it doesn't: when closing the laptop lid, the two sessions get
locked by KDE and the _inactive_ session gets a (hidden by the locking
screen) PolKit authentication screen. The laptop doesn't suspend (as
the action is inhibited by this authentication screen). When opening the
lid, I can unlock the inactive session and authenticate through the
PolKit authentication window and the laptop suspens _then_.

(The doubly annoying factor is that I use fprintd for this inactive
session, which means that on lid closure, the fingerprint reader powers
up, heats _and_ is inaccessible as below the screen. [It powers up for
the PolKit authentication window]).

Now, I've investigated and added a
/etc/polkit-1/localauthority/50-local.d/force-suspend.pkla file with the
following content:
	[Enforce the suspension on lid close]
	Identity=unix-user:*
	Action=org.freedesktop.login1.suspend-multiple-sessions
	ResultInactive=no

(That's a transformation of the corresponding
<allow_inactive>auth_admin_keep</allow_inactive> from
/usr/share/polkit-1/actions/org.freedesktop.login1.policy into
<...>no<...>)

The addition of this file makes the suspension work reliably from any of
the two active sessions, without a prompt on the other (inactive)
session. I suggest changing the value of allow_inactive for
suspend-multiple-sessions to 'no' then.

Is this the consequence of the following output ?

$ systemd-inhibit --list
     Who: PowerDevil (UID 1001/diidier, PID 2595/kded4)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: KDE handles power events
    Mode: block

     Who: PowerDevil (UID 1000/didier, PID 6164/kded4)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key:handle-lid-switch
     Why: KDE handles power events
    Mode: block

     Who: NetworkManager (UID 0/root, PID 912/NetworkManager)
    What: sleep
     Why: NetworkManager needs to turn off networks
    Mode: delay

3 inhibitors listed.

(aka 2 powerdevils launched, and blocking suspend by default ?)

Please ask if you need other details on my setup.

Cheers,

OdyX

Comment 1 Lennart Poettering 2015-02-04 17:15:31 UTC

If KDE wants to handle the lid switch on its own, then it needs to install PK glue so that it has the rights to do so in all cases... It also should stop handling the lid switch if it is not in the fg.

I am not entirely sure why KDE wants to handle it on its own. It could just leave this to logind, and all would be good, like GNOME does it.

Anyway, this is something to fix in KDE I figure, not in logind. Closing.

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.