power manager / session manager interaction

[Oswald Buddenhagen]

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