After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 585614 - use better ConsoleKit shutdown api
use better ConsoleKit shutdown api
Status: RESOLVED OBSOLETE
Product: gnome-session
Classification: Core
Component: gnome-session
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
: 603783 608367 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-06-13 00:21 UTC by Matthias Clasen
Modified: 2012-09-05 16:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch (26.25 KB, patch)
2009-06-13 00:23 UTC, Matthias Clasen
none Details | Review
updated patch against 2.27.4 (24.13 KB, patch)
2009-07-16 00:38 UTC, Matthias Clasen
committed Details | Review
First pass at using the CK API described in fdo bug (44.69 KB, patch)
2010-01-21 00:18 UTC, Vincent Untz
none Details | Review
first round of fixes (49.87 KB, patch)
2010-02-06 04:01 UTC, Matthias Clasen
none Details | Review
basically working now (69.12 KB, patch)
2010-02-08 13:36 UTC, Matthias Clasen
none Details | Review

Description Matthias Clasen 2009-06-13 00:21:04 UTC
Here is a preliminary patch, but this needs more thorough work, with a better ConsoleKit api for shutdown. See http://mail.gnome.org/archives/gdm-list/2009-June/msg00007.html
Comment 1 Matthias Clasen 2009-06-13 00:23:17 UTC
Created attachment 136480 [details] [review]
patch
Comment 2 Matthias Clasen 2009-07-16 00:38:16 UTC
Created attachment 138489 [details] [review]
updated patch against 2.27.4
Comment 3 Vincent Untz 2009-07-29 01:33:40 UTC
Matthias: has there been any movement on the better ConsoleKit API for shutdown? I quickly looked at the gdm and ConsoleKit list archives and I don't see anything :/ I'm a bit reluctant to commit the current patch in its current form.

(btw, you can remove try try_system_restart() and try_system_stop() too in the patch)
Comment 4 Matthias Clasen 2009-07-29 01:36:04 UTC
No, I haven't found anybody to push this on, and didn't have the cycles to do it myself...
Comment 5 André Klapper 2009-08-25 21:07:00 UTC
So we're stuck here for 2.28? :-/
Comment 6 Matthias Clasen 2009-08-25 21:12:31 UTC
yeah.

I blame session saving.
Comment 7 Vincent Untz 2009-08-26 09:10:54 UTC
Err, I committed the patch yesterday before rolling the tarball :-) Just forgot to comment there that we keep the bug open to track the remaining issues because of CK limitations.
Comment 8 André Klapper 2009-08-31 17:14:00 UTC
Basic stuff in --> removing gnome-target
Comment 9 Matthias Clasen 2009-10-14 03:52:39 UTC
https://bugs.freedesktop.org/show_bug.cgi?id=24493 has ConsoleKit patches
Comment 10 Vincent Untz 2009-12-22 13:22:48 UTC
*** Bug 603783 has been marked as a duplicate of this bug. ***
Comment 11 Vincent Untz 2010-01-21 00:18:02 UTC
Created attachment 151899 [details] [review]
First pass at using the CK API described in fdo bug

Here's a first pass at the patch.

I'm pretty sure it doesn't work since I didn't even test it (I didn't compile ConsoleKit with the patches), but at least it compiles. And hopefully, it shouldn't be too bad.

A few comments:

 + the patch ignores the inhibits that CK gives us when it returns from QueryStop, but we have the number of inhibits, so we could easily do something (look for TODO in the code). So assuming the code works fine, it might look like there's no change compared to before. Except that if you cancel the PK authentication for shutdown/reboot, gnome-session should go back to the running phase.

 + many FIXME and a few TODO here and there. It's mostly some notes to myself to make sure it's as solid as possible.

 + I'm not sure how to handle a CK daemon that doesn't have the new API. We could just ignore it, I guess. Actually, I'm not even sure how to detect the case.

 + should we display something if there are other sessions, but no inhibitor at all?

 + if the restart/shutdown is blocked because of a CK inhibitor and only because of this, we might want to monitor CK and continue the restart/shutdown once the CK inhibitor is gone. I didn't look if there's API in CK for this in the CK patches. (Or well, on a more general note, we'd want to update the inhibit dialog anyway)
Comment 12 Matthias Clasen 2010-02-06 04:01:03 UTC
Created attachment 153126 [details] [review]
first round of fixes

Hey Vincent, here is a update of your patch that fixes some of the issues I found while trying it against the rebased CK patches that I put in the CK bug.

The most important fix was that some of the new api is actually on the Session interface, not on Manager.

But the patch still has some fundamental issues:

It doesn't follow the outline in the CK docs:

      <orderedlist>
        <listitem><para>User initiates Shutdown operation</para></listitem>
        <listitem><para>Session leader calls QueryStop() on the ConsoleKit manager object</para></listitem>
        <listitem><para>ConsoleKit emits the QueryStop signal on all session objects</para></listitem>
        <listitem><para>All sessions enter their QueryEnd phase</para></listitem>
        <listitem><para>All session leaders respond back with StopResponse()</para></listitem>
        <listitem><para>The initial QueryStop() call returns</para></listitem>
        <listitem><para>Session leader uses GetSessions() and GetInhibitors() to assemble information to present to the user, in addition to its own inhibitors. Depending on the can_proceed value returned by QueryStop(), the dialog will offer the user to proceed with the shutdown operation</para></listitem>
        <listitem><para>Assuming the user chooses to proceed, the session leader calls Stop() or Restart()</para></listitem>
        <listitem><para>ConsoleKit sets the Stopping property</para></listitem>
        <listitem><para>ConsoleKit verifies that the user has the necessary privileges</para></listitem>
        <listitem><para>ConsoleKit emits the Stop signal on all session obj        <listitem><para>Session leader uses GetSessions() and GetInhibitors() to assemble information to present to the user, in addition to its own inhibitors. Depending on the can_proceed value returned by QueryStop(), the dialog will offer the user to proceed with the shutdown operation</para></listitem>ects</para></listitem>
        <listitem><para>All sessions enter their End phase</para></listitem>
        <listitem><para>All session leaders respond back with StopResponse()</para></listitem>
        <listitem><para>ConsoleKit shuts down the machine</para></listitem>

What your patch does is roughly the following:

- User initiates Shutdown
- Session leader enters QueryEnd phase
- QueryEnd phase ends
- Session leader calls QueryStop on ConsoleKit
- ConsoleKit emits QueryStop signal
- Session leader responds right away, other sessions enter their QueryEnd phase
...

One consequence of this order is that you don't get an inhibit dialog anymore when the QueryEnd phase is entered for another reason (eg the user initiates a logout instead of a shutdown), since you moved the showing of the inhibit dialog from query_end_session_complete to on_consolekit_query_stop_completed (where we never go in the logout case).
Comment 13 Matthias Clasen 2010-02-08 13:36:02 UTC
Created attachment 153265 [details] [review]
basically working now
Comment 14 Vincent Untz 2010-03-09 02:35:16 UTC
*** Bug 608367 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Clasen 2011-08-27 04:11:56 UTC
I consider this work obsolete now, considering ConsoleKit is on the way out.