power manager / session manager interaction

[Brian J. Tarricone]

Hi all,

Not sure if this is the best place for a discussion about this, but it
relates to cross-desktop standards, so... here goes.

Currently xfce4-session is capable of (upon request) shutting down,
rebooting, suspending, and hibernating the system (the first two through
HAL or a sudo-based helper, the last two through HAL).

Personally, I've always thought it questionable that the session manager
should be dealing with it at all, but over in Xfce-land we didn't have
anything 'higher' in the stack to handle it, and users want a GUI way of
shutting down and rebooting, so... there you have it.

More recently, someone wrote us a nice power manager for Xfce, and
adopted the org.freedesktop.PowerManagement interface.

So then we got into a little trouble.  An example:

1.  User asks power manager to shut down the system.
2.  System shuts down, session manager has no clue, and doesn't save the
session or tell apps the session is sending so they have a chance to
prompt the user about any unsaved work.

How do we solve this in a cross-desktop manner?  Here's an idea:

1.  User asks power manager to shut down the system.
2.  Power manager connects to session manager via XSMP and tells the SM
to log out.
3.  SM logs out.
4.  Power manager waits for its X connection to die and then shuts down
the system.

But there's a problem with that too, though it's mainly cosmetic: on a
faster system, the user will see a login dialog before/while the system
is shutting down, because the session manager just quit, which caused X
to quit, which usually brings you back to GDM, or KDM, or slim, or
qingy, or whatever.  Most machines take longer to shut down than they
take to bring up a new X server and start a display manager.

Another route would be to always go through the session manager first
(when asking for a reboot or shutdown), which will take care to end the
session cleanly and then ask the power manager to handle the rest, but
we of course can't keep other apps from asking the power manager to shut
down or reboot.

So I'm not really sure where to go from here.  I'd rather not invent
some private interface so xfpm and xfce4-session can work out this sort
of thing.  People might want to use g-p-m with Xfce, or they might want
to use xfpm elsewhere, and that would make them somewhat deficient
outside their primary environment.

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.

Thanks,
Brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

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.

first, let's introduce the characters:

- stake holders
  - my not want the system to go down
  - may want the system to be up again at a specified time
  - are user sessions, batch processes (e.g., backup), etc.

- hal (or its successor, heh)
  - is the master of system state, including power state
  - has a list of stakeholders. this can be arbitrarily
    (over-)engineered, so let's postpone the details.

- 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)

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

- power managers
  - are mostly dumb hal clients
  - offer system suspend options, subject to policykit restrictions
  - imo, should not offer shutdown options, as these interfere with the
    domain of the session managers

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

- 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.

- 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


now, this isn't entirely thought out, but i guess it's a starting point.
discuss! :)
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg