power manager / session manager interaction
Brian J. Tarricone
bjt23 at cornell.edu
Mon Jul 20 15:45:06 PDT 2009
On 07/17/2009 05:14 AM, Oswald Buddenhagen wrote:
> 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
> - 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
> - imo, should not offer shutdown options, as these interfere with the
> domain of the session managers
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
> 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
> - 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
> - stakeholders are expected to unregister within a reasonable amount of
> - 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.
More information about the xdg