Summary: | sys-auth/consolekit: console-kit-daemon started not by an init script | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Toralf Förster <toralf> |
Component: | Current packages | Assignee: | Daniel Gryniewicz (RETIRED) <dang> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | atswartz, freedesktop-bugs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Toralf Förster
2011-01-13 12:31:34 UTC
if you check what packages on your system have USE=consolekit or depend on consolekit, you'll see that it might be required by pambase which enables console logins to be managed by consolekit. This is not a bug, that's what consolekit is designed for. If I understood you correctly, the error is that console-kit was in the wrong runlevel at my system ? (I'm asking b/c kde-base/solid-4.4.5 needs hald, hald needs consolekit, that init.d script however returned an error == no working KDE if system was booted with "init 2".) I'd like to re-open this bug if portage adds console-kit to the default level whereas it is necessary to be putted eithe into boot level - or - pambase learns to start the console-kit's init.d script instead running console-kit itself - or - the init.d of console-kit doesn't returns an error if console-kit is already running although with parameter --nodaemon started (by pambase ?) The runlevel "default" was adviced here too, but seems to be not the best solution : https://forums.gentoo.org/viewtopic-t-858965-highlight-.html?sid=216a8ef02b9a8e2dcdd56fba4c059d56 the problem comes from hal requiring the consolekit service to be available when starting if I remember correctly. If you don't use hal, don't use the init script. Otherwise, nothing much we can do, it cannot be placed in boot runlevel for simple reasons like "needs /usr". It is also not meant to be run with nodaemon or timed-exit in normal conditions. (In reply to comment #5) > If you don't use hal, don't use the init script. stable kde needs hald (comment #2) > Otherwise, nothing much we can do :-( I was having this problem. * Starting ConsoleKit daemon ... * start-stop-daemon: did not create a valid pid in `/var/run/ConsoleKit/pid' [ !! ] * ERROR: consolekit failed to start Even though consolekit worked fine. I noticed that on another nearly identical install I had a link from net.eth0 to net.lo lrwxrwxrwx 1 root root 18 Mar 23 15:21 /etc/init.d/net.eth0 -> /etc/init.d/net.lo I believe that rc-update add net.eth0 default will create the link. Once this link was created, I no longer got the above message at boot. The ConsoleKit daemon now started correctly at boot and stopped correctly at shutdown. Reading through the comments in this bug, I fail to find any bug here, only expected behavior. To summarize: - consolekit should be at runlevel 'default' - ... and if consolekit is missing run runlevels, it's expected that dbus and/or pam_ck_connector.so will launch one anyway, at this point it's an user error. - hald should not be in any runlevel - ... in fact, sys-apps/hal should not be installed at all, it's obsolete and will be removed from portage very soon (In reply to comment #8) > - ... and if consolekit is missing run runlevels, it's expected that dbus s/run/from/ (In reply to comment #8) > Reading through the comments in this bug, I fail to find any bug here, only > expected behavior. > > To summarize: > > - consolekit should be at runlevel 'default' > - ... and if consolekit is missing run runlevels, it's expected that dbus > and/or pam_ck_connector.so will launch one anyway, at this point it's an user > error. > - hald should not be in any runlevel > - ... in fact, sys-apps/hal should not be installed at all, it's obsolete and > will be removed from portage very soon consolekit was at runlevel 'default', hal was not installed. I was not implying that this was a bug, just how I was able to eliminate the * start-stop-daemon: did not create a valid pid in `/var/run/ConsoleKit/pid' [ !! ] * ERROR: consolekit failed to start even though consolekit functioned properly in either case. Well, again. The issue doesn't have anything to do with hal. Instead it is a misbehaviour of the init script of consolekit. If consolekit was started by a third-party application, then the init.d script doesn't detect it. This happens if my system is started in runlevel "2". Later I'm not able to start kdm b/c the xdm init script depends on consolekit ... tl;dr: tip for ppl experiencing bad pid issue for consolekit && has rc_start_wait set to something non-zero: increase the value (500 works for me) --- so i was having this issue (the bad pid message w/ consolekit in my default runlevel), and i couldn't fix this to no avail. i tried various settings of rc_parallel, and tried moving consolekit to the boot runlevel. i then ran across this comment [1] in an old, related bug. basically, the phrase "start-stop-daemon just checks for the pid file too early" triggered the thought that i had the rc_start_wait set to the suggested default of 100. i tried 500, and consolekit is happy being in the default runlevel w/o any troubling error messages. yay. 1. http://bugs.gentoo.org/show_bug.cgi?id=238468#c15 |