power manager / session manager interaction

[Brian J. Tarricone]

On 07/17/2009 05:14 AM, Oswald Buddenhagen wrote:
> hi,
>
> On Fri, Jul 17, 2009 at 01:20:15AM -0700, Brian J. Tarricone wrote:
>> Is there a recommended best practice for how the power manager and
>> session manager should interact during session end?  Are there other
>> interfaces for synchronising this sort of things that I've forgotten.
>> Any advice would be appreciated.
>>
> to my knowledge, there is no clean integrated solution as of now. so let
> me present my vision to you.

Well, I was more interested in the current state of things.  Honestly I 
don't have time on my plate to develop a new quasi-standard for this 
sort of thing.

I was hoping Richard (or maybe someone else knowledgeable) might have 
time to explain a little bit how gnome-power-manager interacts with 
gnome-session, ConsoleKit (and gdm?).  Or if someone from KDE might have 
a few minutes to spare to explain how this works on KDE.  (I'm not sure 
KDE even uses org.freedesktop.PowerManagement... this might be another 
example of a GNOME thing that somehow ended up with an org.freedesktop.* 
interface without much consensus.)

There was a discussion back in March/April 2007 about all this stuff, 
but after skimming it I'm not actually clear on how the interface is 
supposed to fit in the bigger picture.

> - login managers
>    - are the masters of user session type stakeholders:
>    - the x display manager
>      - as the gnomers plan it, this will be a tight couple of the actual
>        display manager and consolekit
>    - the good ol' login process - possibly also on top of consolekit?
>    - remote tty login servers (ssh, rsh, telnet), ultimately also with
>      consolekit integration (through pam)

The (personal) problem I have with login managers is that Xfce doesn't 
have one.  We suggest people use slim, qingy, or even gdm.  With that in 
mind, I would prefer to have the power management stuff work without 
having to rely on a login manager.  For normal logout, the session 
manager can just exit, and the display manager will take over (or not), 
and we don't need to care about it.  For 
suspend/hibernate/shutdown/reboot, I'd prefer if we don't have to 
involve a login manager.  Talking to consolekit is fine to figure out if 
others are logged in and if we still have permission to complete the 
action based on that, but the login manager seems like it doesn't need 
to be a player here.  (It's probably required for fast user switching, 
but I see that as a different, if related, problem domain.)

> - session managers
>    - are the masters of the state within each user session

Sure.

> - power managers
>    - are mostly dumb hal clients

Yes, this is how I'd like to look at it.

>    - offer system suspend options, subject to policykit restrictions

Yup.

>    - imo, should not offer shutdown options, as these interfere with the
>      domain of the session managers

Agreed.

Currently xfce4-power-manager doesn't expose shutdown/reboot in its UI, 
but it does forward Reboot() and Shutdown() methods to the session 
manager (which xfce4-session does handle by calling into HAL).  I've 
talked to Ali (the xfce4-power-manager author), and I think we've worked 
out how we want to do it, so xfpm is a bit "dumber" and will just shut 
down or reboot when requested.  If a user somehow ends up directly 
asking the power manager to shut down or reboot, they lose their state, 
but the session manager will perform a normal logout before calling 
org.freedesktop.PowerManager.Shutdown().

> then, on with the actual play:
>
> - system boots, starts hal and login managers
>
> - some stakeholders may get registered with hal
>
> - user logs in
>    - login manager registers user session as stakeholder

Somewhat off-topic, but I wonder how this works.  If I do 
ck-list-sessions on my machine, I do get information about an active 
session, though x11-display and x11-display-device are blank.  I'm not 
entirely sure who set up this session in CK -- I assume it must have 
been PAM or qingy, because otherwise if it was Xorg, I imagine those 
fields would be filled in.  And I know xfce4-session didn't do it.  I 
suspect PAM, since I have a /lib/security/pam_ck_connector.so file, that 
lib is mentioned in some files in /etc/pam.d/.

So if that's the case, and PAM is registering a new session, I guess no 
one else ever needs to set up a session via consolekit, since presumably 
all possible sessions on the machine will start through PAM. (I guess 
maybe Xorg or the session manager should be filling in the x11-display 
and x11-display-device properties later, but apparently that's not 
getting done for me.)

> - other stakeholders may get registered with hal
>
> - user wants to shutdown from within a running session
>    - this begs for putting this into the hands of the session manager
>
> - the session manager asks hal for a shutdown
>
> - hal calls back to each registered stakeholder
>
> - sessions which are on the same seat and belong to the same user as the
>    requesting session (including that one itself, obviously) will say
>    yes, everyone else says no.

I'm a bit confused as to how this is determined.  If the session manager 
asks the power manager to shut down, and it's allowed, then it will 
happen immediately.  If it's not allowed, then it will fail.

Does this require PolicyKit integration?  Before calling 
org.freedesktop.PowerManagement.Shutdown(), should the session manager 
first call into PolicyKit to see if shutdown is allowed?  There's also 
org.fd.PowerManagement.CanShutdown(), but how does this really work?  It 
seems a binary "yes/no" answer here isn't enough -- it might be 
"yes/no/if you authenticate" -- or will the latter case also return 
"yes" and assume that the user will authenticate.

Then it's even more complicated.  The session manager presumably wants 
to log the user out before actually asking for a shutdown.  So really it 
needs to do something like this:

1.  Ask PolicyKit if the user is allowed to shut down.
2.  If so, ask ConsoleKit if other users are logged in.
3.  If so, ask someone (PolicyKit?) if the user is allowed to force a 
shutdown even if other users are logged in.
4.  If so, possibly present an authentication dialog.
5.  If that all completes, log out the current user, which may involve 
applications prompting to save unsaved data, which may even involve 
canceling shutdown entirely.
6.  If session logout completes successfully, then we finally ask the 
power manager to shut down.
7.  The power manager shuts the system down (not sure if it should be 
calling into HAL/DK-power for this, or just into CK).

Now, this isn't quite sufficent for Xfce, because we don't currently 
have any PolicyKit support, and I'm not planning on adding any at least 
until the API redesign is done and stable (if even that soon).  But at 
least this might be a good overview of what's supposed to happen when 
we're making use of all available technologies.

The problem from my perspective is in how to layer all this from the 
session manager's viewpoint.  If I leave out PolicyKit support for now, 
and assume the underlying system won't require it, is a call to 
org.freedesktop.PowerManagement.CanShutdown() all that is necessary to 
determine if calling Shutdown() will work or not?  Actually -- even if 
PK is present, should calling CanShutdown() be all that's necessary, or 
will the session manager still have to talk to PK independently?

Of course, I still don't see how the session manager can avoid talking 
to PK.  Take this scenario:

1.  User requests shutdown.
2.  Session manager calls org.fd.PM.CanShutdown(), which returns true.
3.  Session manager logs the user out.
4.  Session manager calls org.fd.PM.Shutdown(), which then presents a 
dialog to the user to authenticate (because there are other users with 
active sessions, or something).
5.  User cancels the dialog, or is unable to authenticate, or whatever.
6.  Now user has a blank screen because they're already logged out.

That's obviously not desirable.  Between #2 and #3 the session manager 
will want to be sure that org.fd.PM.Shutdown() will succeed without 
extra user interaction, and will want to talk to PK to make sure that 
will work.

> - if anyone said no:
>
>    - the session manager may present the list of blockers to the user and
>      query policykit whether this user has rights to force a shutdown
>
>    - if override is chosen, the session manager sends a forced shutdown
>      request to hal
>
>    - hal may instruct policykit to pop up an authentication dialog
>
>    - in case of lacking privileges, the session manager may ask the
>      user whether to "downgrade" the shutdown to a logout. in any case
>      the shutdown as such is canceled.
>
> - hal sends a first shutdown request to all stakeholders
>
> - the x display managers will instruct the session managers to translate
>    this to xsmp saveyourself requests
>
> - sessions at the requesting seat which belong to the requesting user
>    may ask the usual "save/discard/cancel" questions (consolekit will
>    switch to each console in turn). obviously, any of these sessions may
>    cancel the shutdown at this stage.
>
> - the "other" sessions should save themselves, but have no further
>    veto right
>
> - now hal sends a final shutdown request to all stakeholders
>
>    - this will translate into an xsmp die request for active x sessions
>
>    - the login manager should not auto-respawn x displays whose sessions
>      exit
>
> - stakeholders are expected to unregister within a reasonable amount of
>    time
>
>    - before they do, they may request an auto-boot
>
> - hal initiates the actual shutdown, possibly programs rtc for auto-boot

This all sounds reasonable.

Really, I just want to get an idea of how the "big picture" should work, 
while taking advantage of all the various technologies.  At present I 
don't plan to implement the big picture in xfce4-session, but I'd like 
to get an idea of the best way to do it such that I can incrementally 
add support for things like PolicyKit later on, while still having 
something functional now.

	-brian