Difference between revisions of "ConsoleKit"

From ArchWiki
Jump to: navigation, search
m (It's not like unused threads use a lot of CPU time.)
m (Running several applications from ~/.xinitrc)
Line 34: Line 34:
 
If several applications are to be executed from {{ic|~/.xinitrc}}, not all of these will have ConsoleKit environment variables set. In the following example, only children of Compiz will be able to properly use ConsoleKit, but children of xterm will not.
 
If several applications are to be executed from {{ic|~/.xinitrc}}, not all of these will have ConsoleKit environment variables set. In the following example, only children of Compiz will be able to properly use ConsoleKit, but children of xterm will not.
  
xterm &
+
{{hc|~/.xinitrc|
exec ck-launch-session compiz ccp
+
xterm &
 +
exec ck-launch-session compiz ccp
 +
}}
  
 
Typically, this can be an issue when for example using Compiz standalone and some other application launchers, (gnome-do, kupfer, gmrun, xbindkeys, etc.) since children of the application launcher will not be able to use ConsoleKit. A dirty workaround is to have the entire session started by a second script, e.g. {{ic|~/.xstart}}. Do not forget dbus-launch, it is likely that you will need it too:
 
Typically, this can be an issue when for example using Compiz standalone and some other application launchers, (gnome-do, kupfer, gmrun, xbindkeys, etc.) since children of the application launcher will not be able to use ConsoleKit. A dirty workaround is to have the entire session started by a second script, e.g. {{ic|~/.xstart}}. Do not forget dbus-launch, it is likely that you will need it too:
Line 50: Line 52:
  
 
Do not forget to make {{ic|~/.xstart}} executable:
 
Do not forget to make {{ic|~/.xstart}} executable:
 +
 
  $ chmod +x ~/.xstart
 
  $ chmod +x ~/.xstart
  
 
To see whether everything is started correctly:
 
To see whether everything is started correctly:
 +
 
  $ ck-list-sessions
 
  $ ck-list-sessions
It should show at least one session like this one
+
 
 +
It should show at least one session like this one:
 +
 
 
  Session18:
 
  Session18:
 
         unix-user = '1000'
 
         unix-user = '1000'

Revision as of 11:12, 26 August 2012

Note: From ConsoleKit's website:
ConsoleKit is currently not actively maintained. The focus has shifted to the built-in seat/user/session management of Software/systemd called systemd-loginctl.

ConsoleKit is a framework for managing user sessions and permissions. Some of the most common usages of ConsoleKit are allowing non-root users to mount removable media and suspending/shutting down the computer through common desktop applications (e.g. Thunar, Nautilus, the GNOME shutdown menu, etc.).

If you mind using an unmaintained application and you only want a convenient way to mount disks as user, have a look at udev, udiskie and polkit. Otherwise you might consider switching to systemd.

Installation

Install the consolekit package, available in the official repositories.

Display manager usage

ck-launch-session

To launch an X session with ConsoleKit, append the following to the exec statement in ~/.xinitrc e.g.:

exec ck-launch-session openbox-session

This starts Openbox with proper environment variables so it and its children are able to use ConsoleKit.

Display managers like KDM, GDM, LXDM and SLiM start ConsoleKit automatically with each X session.

Note:
  • Do not nest ConsoleKit sessions by calling one from another, or you will break ConsoleKit.
  • In particular, since SLiM reads ~/.xinitrc, you should make sure not to run ck-launch-session there.

Running several applications from ~/.xinitrc

If several applications are to be executed from ~/.xinitrc, not all of these will have ConsoleKit environment variables set. In the following example, only children of Compiz will be able to properly use ConsoleKit, but children of xterm will not.

~/.xinitrc
xterm &
exec ck-launch-session compiz ccp

Typically, this can be an issue when for example using Compiz standalone and some other application launchers, (gnome-do, kupfer, gmrun, xbindkeys, etc.) since children of the application launcher will not be able to use ConsoleKit. A dirty workaround is to have the entire session started by a second script, e.g. ~/.xstart. Do not forget dbus-launch, it is likely that you will need it too:

~/.xinitrc
exec ck-launch-session dbus-launch ~/.xstart
~/.xstart
xterm &
thunar &
compiz ccp

Do not forget to make ~/.xstart executable:

$ chmod +x ~/.xstart

To see whether everything is started correctly:

$ ck-list-sessions

It should show at least one session like this one:

Session18:
       unix-user = '1000'
       realname = 'Your Name'
       seat = 'Seat1'
       session-type = 
       active = TRUE
       x11-display = ':0'
       x11-display-device = '/dev/tty2'
       display-device = '/dev/tty1'
       remote-host-name = 
       is-local = TRUE
       on-since = '2011-11-16T12:01:50.104764Z'
       login-session-id = '7'

no display manager

If you're not using a display manager, but starting your window manager from startx command, or from initab.

If ConsoleKit is not working (ck-list-sessions command showing active = FALSE), you should start your window manager using the bash_profile method: Start_X_at_Boot#bash_profile.

Use dbus for power operations

  • shut down:
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Stop
  • restart:
dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart
  • suspend:
dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Suspend
  • hibernate (suspend to disk):
dbus-send --system --print-reply --dest="org.freedesktop.UPower" /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

This method assumes that you are given permission to shutdown by policy kit. The default group for this is "wheel". To change this, edit /etc/polkit-1/localauthority.conf.d/50-localauthority.conf

Note: Using dbus for suspend and hibernate requires upower.

More resources