How to shutdown with consolekit without sysvinit (but with systemd)

The objective is to setup an active ConsoleKit session. You can check this via:

$ ck-list-sessions | grep active
    active = TRUE

If there are multiple ConsoleKit sessions only one session at most can be active at a time.

If the output is something like

$ ck-list-sessions | grep active
    active = FALSE
    active = FALSE

you have a problem because things that need an active ConsoleKit session to authenticate for sending messages over dbus do not work (e.g. NetworkManager, i.e. nm-applet, udisk ...).

There are several methods to create (and activate) a ConsoleKit session. The display manager may setup one via directly communicating with the ConsoleKit daemon. Or a pam-module may do it. Or a login/X11-session-init script might call ck-launch-session which should create an active session (modulo bugs).

Usually, the goal should be to setup ConsoleKit in such a way that you get an active session for your window manager or login shell (not just for single scripts).

To test the ConsoleKit system you can try to use ck-launch-session to create a proper consolekit session. For example you can call your script like this:

$ ck-launch-session ./script

To test if ck-launch-session is bug-free you can call

$ ck-launch-session ck-list-sessions

and check if there is an active session.

Bugs: Updates to the ConsoleKit system recently introduced various bugs into the fragile (and over-engineered?) ConsoleKit ecosystem.

For example on my Ubuntu 11.10 system I had to delete nox11 from the pam_ck_connector.so line in /etc/pam.d/common-session after ck-launch-session stopped working after a system upgrade:

--- a/pam.d/common-session      Fri May 25 10:26:53 2012 +0200
+++ b/pam.d/common-session      Fri May 25 10:39:41 2012 +0200
@@ -29,5 +29,5 @@
 session        required        pam_unix.so 
 session        optional                        pam_winbind.so 
 session        optional        pam_ecryptfs.so unwrap
-session        optional                        pam_ck_connector.so nox11
+session        optional                        pam_ck_connector.so
 # end of pam-auth-update config

With that change now I directly get an active session when starting my window manager via WDM login.

That means that the window manager now runs inside an active ConsoleKit session and everything that is started as a child from the window manager process (e.g. from an xterm) is also part of that session, i.e. no need for extra calls of ck-launch-session for e.g. nm-applet any more.

If I understand you correctly, you want to suspend your VB machines before your bash session on tty3 terminates, or before your Xserver terminates.

I believe systemd is unaware of your running Xsession, because you start it from your .bashrc, so it will be difficult to tell systemd to suspend your VBs before it terminates your shell or your Xsession. You will have to find a place in the shutdown sequence which is "early enough", which might be difficult to find and semantically questionable, because it would mix "user stuff" with "system stuff"

The solutions may somewhat depend on how systemd terminates your processes, but the following should at least point in a good direction:

Before the shell terminates

suspendVB() {
        echo "suspending VBs"
        # put real code here
        exit
}

trap suspendVB EXIT

If you make this the rcfile of your bash (or add it to .bashrc), then the code in suspendVB() will be executed before the shell terminates. You can test this by running

bash --rcfile xxx

where the file xxx contains the code from above. This starts another shell inside your current shell, just for testing. When you then run a simple exit, you will see:

martin@beaureve:~$ exit
exit
suspending VBs
/home/martin >

and you are back in your original (login) shell.

You may have to find out how systemd actually terminates your login shells, and you may have to replace EXIT by some other signal(s). Lookup the trap command to find out more.

Note that When systemd kills your processes with "-9" (SIGKILL) then you will not be able to trap the termination, i.e. you're out of luck.

Before the Xsession terminates

Alternatively you may try a similar thing with your Xsession. This is essential in cases where systemd terminates your Xsession before it terminates your shells. You may want to insert a trap in one of the X startup files (e.g. .xinitrc) - lookup the man pages for startx and xinit to find out more.

If your startx file looks something like mine, then the xserver is started in foreground and you can alternatively simply place your suspend commands after the line where X is actually started (and not use traps at all):

xinit "$client" $clientargs -- "$server" $display $serverargs
retval=$?
echo " --- suspending VBs ---"

I put in the line saying "suspending VBs" and when I run startx -- vt8 I get a fullblows (kde) session on vt8 and only when I logout, the line "suspending VBs" appears on the screen.