|
Bugzilla – Full Text Bug Listing |
| Summary: | HAL denies access to its functions after ConsoleKit cannot connect to dbus at boot | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Piotr Kalinowski <pitkali> |
| Component: | Basesystem | Assignee: | Timo Hoenig <thoenig> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P4 - Low | CC: | koenig, mlatimer |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Timo, are you sure that we want to start dbus with startproc? The bug might go away if we block until dbus returns after initialization? Yes, if you say that the dependencies are correct (I haven't checked them) I'm fine with returning only once D-Bus is up and running. Though I'm not yet entirely sure on how to determine if D-Bus is ready in order to return from the rc script at the right time. ConsoleKit does list dbus as Required-Start, which is correct. Moreover, I tried adding a loop to the consolekit script that did checkproc on dbus. Even though dbus was apparently running, that did not help. Wouldn't checking the system bus socket (/var/run/dbus/system_bus_socket, if I recall it correctly) suffice? It does solve the issue for ConsoleKit, as is mentioned in the report (the shell code part). Care to check if removing "startproc" from the init script works? It shouldn't be used. If there is still a window where dbus daemonizing returns before D-Bus being initialized properly, we should fix D-Bus. Confirmed. I commented out the line with startproc and below added: $DBUS_DAEMON_BIN $DBUS_DAEMON_PARAMETER pidof $DBUS_DAEMON_BIN > $DBUS_DAEMON_PID It fixed the problem. Piotr, thanks for testing and finding the bug. I guess D-Bus creates its own pid file, right? We should not need to create it. Timo, please get rid of startproc. Submitted fixed package to STABLE. *** Bug 297569 has been marked as a duplicate of this bug. *** (In reply to comment #7 from Timo Hoenig) > Submitted fixed package to STABLE. the same problem shows up with SLES10/SLED10 SP1: powersaved doesn't run (so shutdown with power button does not work) because of hald not starting correctly: Sep 16 09:19:46 CE2737455 [powersave]: ERROR (MainLoop:85) Haldaemon did not appear. Aborting... this seems to occur _very_ infrequently (about 1 of 50 reboots) for a customer with slightly newer/faster hardware, hasen't been an issue before... is there a fix for SLES10 SP1 available too ? I'll suggest them to remove the "startproc" for dbus and see what happens (will report if they agree it's more stable than now...;) No online update at the moment, thanks. Harald, we will not provide an online update for this one, sorry. |
When parallel script execution is enabled, ConsoleKit may not be able to connect to dbus. As a result power management functions are not accessible from KDE. Also, KDE cannot mount media. The problem disappears after manually starting ConsoleKit (which by then is reportedly 'unused') and logging again. It look as if: 1. dbus is starting. Its script finishes execution, but /var/run/dbus/system_bus_socket is not yet available. 2. ConsoleKit is started and tries to connect to the above-mentioned socket. It fails and reports a warning in syslog. 3. The socket becomes available. 4. The boot continues. On my Core Duo laptop the bug can be reproduced by: 1. Ensuring parallel startup script execution is enabled (seems to be the default.) 2. Booting the system. 3. Right-click kde power management applet and see that no power management functions are available. Try to mount a media (cdrom, e.g.) and get error about access denied by policy. The problem is gone after one of the following: 1. Modifying /etc/PolicyKit/PolicyKit.conf and allowing a certain user to do everything with <match user="id"><return result="yes"/></match>. Apparently PolicyKit considers a user inactive despite logging in. Clearly a ConsoleKit problem? 2. Disable parallel execution of startup scripts. 3. Modifying /etc/init.d/consolekit to include something like: while [ ! -S /var/run/dbus/system_bus_socket ] do sleep 1 done before starting consolekit. Probably something like that should actually be added to dbus script, so that after the script exits the socket is available.