Tips and tricks for ConsoleKit, PolicyKit, and udev helpers

[Havin_it]

login-session-id = '' should never be empty. It's mentioned in the first post of this thread. If it's empty it's almost certainly because of missing CONFIG_AUDITSYSCALL=y kernel option:

Code: Select all

# zgrep AUDITSYSCALL /proc/config.gz 
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /lib/modules/$(uname -r)/build/.config
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /usr/src/linux/.config 
CONFIG_AUDITSYSCALL=y

The kernel option can be worked around using some Display Managers with advanced internal ConsoleKit support, but really, enable it, it's not worth the trouble figuring out which DM works and which doesn't without the option.

Sorry for the delay in answer, but I'm swamped with work lately.

Alas no, I've had the kernel option enabled for some time. Other possibilities?

No worries about delay, this prob is something I learned to tolerate long before I even posted about it

[SamuliSuominen]

login-session-id = '' should never be empty. It's mentioned in the first post of this thread. If it's empty it's almost certainly because of missing CONFIG_AUDITSYSCALL=y kernel option:

Code: Select all

# zgrep AUDITSYSCALL /proc/config.gz 
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /lib/modules/$(uname -r)/build/.config
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /usr/src/linux/.config 
CONFIG_AUDITSYSCALL=y

The kernel option can be worked around using some Display Managers with advanced internal ConsoleKit support, but really, enable it, it's not worth the trouble figuring out which DM works and which doesn't without the option.

Sorry for the delay in answer, but I'm swamped with work lately.

Alas no, I've had the kernel option enabled for some time. Other possibilities?

No worries about delay, this prob is something I learned to tolerate long before I even posted about it

Are you absolutely sure? You can verify by looking if /proc/<pid>/sessionid is available, like:

Code: Select all

# ls -l /proc/`pidof console-kit-daemon`/sessionid
-r--r--r-- 1 root root 0 Apr 17 13:12 /proc/<pid number will be here>/sessionid
# cat /proc/`pidof console-kit-daemon`/sessionid
<some random numbers will be here>

If the sessionid proc information is not available, then even if you have =y when you grep the kernel config some other option masqueraded it, look through menuconfig.

Also good idea to enable CONFIG_IKCONFIG_PROC=y to get /proc/config.gz to get real information from the running kernel, because some people have had old .config picked up
by automated tools like genkernel.

If none of that was the case, continuing...

What's the output of `emerge -pv pambase consolekit` and `grep pam_ck /etc/pam.d/*`? It shoud look like:

Code: Select all

# grep pam_ck /etc/pam.d/*
/etc/pam.d/system-login:-session	optional	pam_ck_connector.so nox11

And...

[ebuild R ] sys-auth/pambase-20120417-r1 USE="consolekit cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux) -systemd" 4 kB
[ebuild R ] sys-auth/consolekit-0.4.5_p20120320-r2 USE="acl pam policykit -debug -doc (-selinux) {-test}" 0 kB

Notice USE="consolekit pam" must be enabled. This is related to getting the pam_ck_connector.so working.

What display manager did you use again? None and startx? What is in your ~/.xinitrc and ~/.xsession? Have you at some point inserted manual ck-launch-session to files in /etc/X11/Sessions?

[Havin_it]

Code: Select all

# zgrep AUDITSYSCALL /proc/config.gz 
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /lib/modules/$(uname -r)/build/.config
CONFIG_AUDITSYSCALL=y
# grep AUDITSYSCALL /usr/src/linux/.config 
CONFIG_AUDITSYSCALL=y

...
Are you absolutely sure? You can verify by looking if /proc/<pid>/sessionid is available, like:

Code: Select all

# ls -l /proc/`pidof console-kit-daemon`/sessionid
-r--r--r-- 1 root root 0 Apr 17 13:12 /proc/<pid number will be here>/sessionid
# cat /proc/`pidof console-kit-daemon`/sessionid
<some random numbers will be here>

10-digit number, check.

If the sessionid proc information is not available, then even if you have =y when you grep the kernel config some other option masqueraded it, look through menuconfig.

Also good idea to enable CONFIG_IKCONFIG_PROC=y to get /proc/config.gz to get real information from the running kernel, because some people have had old .config picked up
by automated tools like genkernel.

I checked all three one-liners you used above, and make menuconfig: all showing =y. I don't use genkernel, just a script that copies my last .config to the new kernel dir and runs "make oldconfig".

If none of that was the case, continuing...

What's the output of `emerge -pv pambase consolekit` and `grep pam_ck /etc/pam.d/*`? It shoud look like:

Code: Select all

# grep pam_ck /etc/pam.d/*
/etc/pam.d/system-login:-session	optional	pam_ck_connector.so nox11

Yep, same. The only non-standard thing I have in pam config is pam_mount, so two files are altered:

/etc/pam.d/system-auth

Code: Select all

auth            required        pam_env.so 
auth            required        pam_unix.so try_first_pass likeauth nullok 
auth            optional        pam_permit.so
auth            optional        pam_mount.so
 
account         required        pam_unix.so 
account         optional        pam_permit.so
 
password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 
password        required        pam_unix.so try_first_pass use_authtok nullok sha512 shadow                                     
password        optional        pam_permit.so                                                                                   
                                                                                                                                
session         required        pam_limits.so 
session         required        pam_env.so 
session         required        pam_unix.so 
session         optional        pam_permit.so
session         optional        pam_mount.so

/etc/pam.d/system-login

Code: Select all

auth            required        pam_tally2.so onerr=succeed
auth            required        pam_shells.so 
auth            required        pam_nologin.so 
auth            include         system-auth
#auth           substack        system-auth
#auth           optional        pam_mount.so
 
account         required        pam_access.so 
account         required        pam_nologin.so 
account         include         system-auth
account         required        pam_tally2.so onerr=succeed 
 
password        include         system-auth
 
session         optional        pam_loginuid.so
session         required        pam_env.so 
session         optional        pam_lastlog.so 
session         include         system-auth
-session        optional        pam_ck_connector.so nox11
session         optional        pam_motd.so motd=/etc/motd
session         optional        pam_mail.so

And...

[ebuild R ] sys-auth/pambase-20120417-r1 USE="consolekit cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux) -systemd" 4 kB
[ebuild R ] sys-auth/consolekit-0.4.5_p20120320-r2 USE="acl pam policykit -debug -doc (-selinux) {-test}" 0 kB

Notice USE="consolekit pam" must be enabled. This is related to getting the pam_ck_connector.so working.

Code: Select all

[ebuild   R    ] sys-auth/pambase-20120417-r1  USE="(consolekit) cracklib sha512 -debug -gnome-keyring -minimal -mktemp -pam_krb5 -pam_ssh -passwdqc (-selinux) -systemd" 4 kB
[ebuild     U  ] sys-auth/polkit-0.110 [0.109-r1] USE="introspection kde nls pam -examples -gtk (-selinux) (-systemd)" 1,358 kB
[ebuild     U  ] sys-auth/consolekit-0.4.5_p20120320-r2 [0.4.5_p20120320-r1] USE="acl pam (policykit) -debug -doc (-selinux) {-test}" 101 kB

[/quote]
Note I'm currently halfway through a world upgrade that crapped out :/

What display manager did you use again? None and startx? What is in your ~/.xinitrc and ~/.xsession? Have you at some point inserted manual ck-launch-session to files in /etc/X11/Sessions?

KDM, no .xinitrc or .xsession, nothing added to Session files.

[Goverp]

My PC has been suffering from various of the problems described in this thread, but was correctly installed and configured. It turned out that the polkitd daemon was dying after every command, and that in turn was due to a segfault in spidermonkey.

It turns out that this problem was caused by overly-aggressive optimization settings when compiling polkit and spidermonkey. Using CFLAGS="-O2 -march=i686" cured the segfault and now polkitd works properly. (For a little more detail, see here.)

[cwr]

Thanks for the summary, Ssuominen - I messed around for most of an afternoon
trying to sort out Gnome 2.x menus and polkit before actually _reading_ your
checklist; one emerge later and it all worked ...

Will

[miroR]

For those like me, who run a single user system, don't suspend/hibernate, and don't use automounting
they don't need to use "ck-launch-session" or the associated "dbus stuff" in their .xinitrc file.

This is my .xinitrc file and yes it works fine.

Code: Select all

#!/bin/sh
#
# ~/.xinitrc
#
exec > /home/don/.xsession-errors 2>&1
# Executed by startx (run your window manager from here)
#-------------
XDG_CONFIG_HOME="$HOME/.config"
XDG_MENU_PREFIX="lxde-"
XSESSION="LXDE"
export XDG_MENU_PREFIX XSESSION XDG_CONFIG_HOME
eval `cat $HOME/.fehbg` &
exec cairo-compmgr &
exec /usr/bin/lxsession -s DON -e LXDE
#-------------
#exec /usr/bin/openbox-session
#-------------
#XDG_MENU_PREFIX="xfce-"
#XSESSION="Xfce4"
#export XDG_MENU_PREFIX XSESSION
#exec /usr/bin/xfce4-session

I get logout and that's all I really need anyway.

Just an FYI

Code: Select all

exec /usr/bin/openbox-session

is the way I want to go.
because:
https://forums.gentoo.org/viewtopic-t-8 ... ml#7164546
which the main points of, in shorter and more poignant, clearer to read fashion, I feel free to repeat here:

...[snip]...They force us to go through all of this just so they can support a very specialized usage case.

How many people do you know who run computers with multiple keyboards and monitors

(
therefore "multi-seat"
)

and need to be sure that random people sitting at those seats around the
computer don't get access they shouldn't?

(
much more in-depth here:
Air-Gapped Gentoo Install, Tentative
https://forums.gentoo.org/viewtopic-p-7 ... ml#7558880
)

...because I don't want to have to accomodate for remote seats.

However I respect opposite views. But I haven't found anywhere a topic that
would allow for:
no-*kits-dbus only single user on my system howto
or the like.

I respect opposite views, so I would like to post my problems to live without
*kits and dbus (problems uninstalling some of them that inadvertently, actually
due to my insufficient understanding earlier, were pulled by some gui packages
(gtk+)...

Advice? Post here to have pro and against in one place, or post separately?

EDIT Thu May 29 19:35:44 CEST 2014, going for a separate topic:
Uninstalling dbus and *kits (to Unfacilitate Remote Seats)
https://forums.gentoo.org/viewtopic-p-7559358.html
Thank you!

Miroslav Rovis
www.CroatiaFidelis.hr

[SDNick484]

Tonight I rebooted for the first time in a month or two, and I noticed my Suspend, Shut Down, etc. were greyed out in my menu in XFCE. After some research, it seems the "consolekit" use flag is now masked (i.e. it shows up in parentheses if you do an emerge -pv on a package that has it) in some profiles which is a problem because pambase requires it. To fix the issue, I had to unmask the use flag by creating /etc/portage/profile/use.mask with the content "-consolekit" (no quotes, yes, it starts with a -, think of it like a double negative). Once I did that, I rebuilt pambase, restarted dbus, re-logged in, and started X, and the options are now selectable.

[PF4Public]

Solution: check the permission of /usr/libexec/dbus-daemon-launch-helper. It should be o+x.

See my monologue:http://forums.gentoo.org/viewtopic-t-905298.html

If it already reported, pls, ignore this.
Bests.

Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success

This has been covered by this same thread 2-3 times if take the time to read all the conversation.

Tends to boil down to:

# emerge -1va dbus dbus-glib

And if that doesn't help:

# emerge -1vae dbus dbus-glib

Failed to execute program /usr/libexec/dbus-daemon-launch-helper: Success

This has been covered by this same thread 2-3 times if take the time to read all the conversation.

Tends to boil down to:

# emerge -1va dbus dbus-glib

I had already done that, to no avail, several times before I found this thread.

And if that doesn't help:

# emerge -1vae dbus dbus-glib

In fact, I'm being more aggressive and running an "emerge -vtae @world" since yesterday.
Will post the result when done.

The solution for me is/ was

chmod o+x /usr/libexec/dbus-daemon-launch-helper

after that all is well and i´m happy

With a fresh install, I had to do the same. I don't really understand why...

Also for me.
Even after an "emerge -vtae @world", followed by an "emerge -1vae dbus dbus-glib", the failure was still there

So, what is the real issue with dbus-daemon-launch-helper and what is the proper way of fixing this? I've found a bug report at RedHat's bugtracker, where it was hinted, that this file should be owned by root:dbus, but we do not have dbus group.

Edit: after reemerging dbus and dbus-glib this helper got owned by root:messagebus. So, I suppose, it should suffice to simply chown this helper to be owned by root:messagebus.