ConsoleKit doesn't keep state over restarts

[Alan Jenkins]

Binary package hint: policykit

i.e. it seems that after

    /etc/init.d/hal restart

I get

    alan@alan-eeepc:$ users-admin

    ** (users-admin:1651): CRITICAL **: Launch helper exited with unknown return code 0

and the "Unlock" button is greyed out.

This is also likely related to the following log messages:

    May 16 20:03:27 alan-eeepc console-kit-daemon[1655]: WARNING: Failed to acquire org.freedesktop.ConsoleKit
    May 16 20:03:27 alan-eeepc console-kit-daemon[1655]: WARNING: Could not acquire name; will retry
    May 16 20:03:30 alan-eeepc console-kit-daemon[1655]: WARNING: Failed to acquire org.freedesktop.ConsoleKit
    May 16 20:03:30 alan-eeepc console-kit-daemon[1655]: WARNING: Could not acquire name; will retry

[Chris Coulson (chrisccoulson)]

You mention DBUS in the title and HAL later on. Which one is it? Obviously, if you restart DBUS then HAL gets restarted anyway (along with lots of other stuff).

Why are you trying to restart DBUS anyway? It causes all sorts of horrible problems (not just with PolicyKit). I've just tried restarting DBUS on my machine for the hell of it, and ended up just having to reboot afterwards because everything was just such a mess (no Network Manager, couldn't log out or switch user etc).

I really don't think this is a valid bug against PolicyKit.

[Alan Jenkins (aj504)]

Sorry, I meant dbus, i.e.

/etc/init.d/dbus restart

and I'm aware that this does involve restarting a lot of stuff. I suspect you're right and this may not a bug specific to PolicyKit, but it is a valid bug. DBus services should be able to cope with being stopped and restarted like runlevel services are.

Can you confirm whether you saw the same console-kit-daemon messages in /var/log/daemon.log ? I'll see if I can reproduce this just by restarting that specific bus service, then we could move it to the console-kit-daemon package.

Interestingly it seems I can get the "unlock" button working again simply by logging out and back in again.

It's odd that you say it broke NetworkManager for you - mine keeps on working. I'm using Kubuntu and the KDE applet though - maybe the GNOME one isn't as robust. It would be great if you could isolate some of your issues - e.g. does restarting the NetworkManager service break nm-applet? - and file them against the relevant packages.

Obviously I didn't have any trouble logging out either - so perhaps KDM is more robust than GDM, or maybe it just doesn't use new dbus services. I'm not sure what switch user is doing on my computer though. Hmm. The login manager type issues you describe aren't too surprising if console-kit-daemon is not working.

Thanks for looking at this

[Alan Jenkins (aj504)]

Right. Manually killing and restarting console-kit-daemon is sufficient to trigger this problem. I don't have complete information, but I still believe this is a bug in PolicyKit as well as console-kit-daemon.

My educated guess is that when console-kit-daemon is restarted, it forgets who's logged in. The information IS available - because the "w" command is quite capable of telling me who's logged in without running a daemon. So from my point of view that's a fairly damning bug in console kit (because it suggests the authors ignored the existing login/logging mechanism).

My understanding of PolicyKit is even more vague. However, my expectation is that system administration GUIs such as users-admin should be as robust as possible. I can't immediately think of a realistic situation where this would be critical and you really don't want to reboot to get PolicyKit working after console-kit-daemon has crashed. Nevertheless, the thought doesn't make me feel warm and fuzzy.

[Neil Mclean (nwmclean)]

Whenever I run Likewise-Open-gui to connect to the corporate domain in my office, after successfully joining the domain it seems my desktop jumps through some hoops, screen flickers a few times, nautilus opens a window to my home folder, nm-applet disappears, and when I check my syslog it is being flooded with the same message:
console-kit-daemon[5583]: WARNING: Could not acquire name; will retry.
console-kit-daemon[5583]: WARNING: Failed to acquire org.freeedsktop.ConsoleKit

Cheers

[Laurent Bonnaud (laurent-bonnaud)]

I am seeing this bug, too. Here is a summary:

 - because of dbus buggyness I have to restart it sometimes:

# /etc/init.d/dbus restart

(I know how to fix the mess afterward and how to get networkmanager working again :>)

 - one of the consequences is that two console-kit-daemon processes are running:

$ ps aux | grep console
root 6102 0.0 0.1 13140 2892 ? Ssl May26 0:14 /usr/sbin/console-kit-daemon
root 24182 0.0 0.0 8868 1956 ? Ssl 09:24 0:00 /usr/sbin/console-kit-daemon

(/etc/init.d/dbus starts the second one but fails to kill the first one)

 - the new console-kit-daemon process spams my syslog with the following messages (one message every 3 seconds !):

May 29 09:45:03 vougeot console-kit-daemon[24182]: WARNING: Failed to acquire org.freedesktop.ConsoleKit
May 29 09:45:03 vougeot console-kit-daemon[24182]: WARNING: Could not acquire name; will retry

There are at least 3 things to fix to improve the situation:

 1. fix the original dbus problem (I will report another bug for this...)
 2. have /etc/init.d/dbus kill old console-kit-daemon processes
 3. reduce the number of console-kit-daemon warning messages to one

[James Westby (james-w)]

Hi,

Has anyone reproduced this on latest Intrepid?

As Chris said, restarting dbus is a really bad idea, and you should never
do it. I believe this issue may have been fixed regardless of that.

Thanks,

James

[Lukas Hejtmanek (xhejtman)]

> As Chris said, restarting dbus is a really bad idea, and you should never do it.

are you kidding?? what about upgrading dbus package that restarts dbus? do not even think of saying upgrading dbus is a really bad idea.

[Chris Coulson (chrisccoulson)]

Lukas - Upgrading dbus doesn't restart the dbus service. After upgrading dbus, you will be prompted to reboot.

[WillDyson (will-dyson)]

> Lukas - Upgrading dbus doesn't restart the dbus service. After upgrading
> dbus, you will be prompted to reboot.

Ubuntu95 has detected a change in your system configuration. Reboot to activate?

:P

For what it's worth, I was able to reproduce this just now. Restart
dbus, consolekit no-longer thinks I am logged in.

[Lukas Hejtmanek (xhejtman)]

I'm pretty sure that apt-get update/upgrade does restart dbus and no prompt for reboot appears. I would not accept boot anyway.

[Chris Coulson (chrisccoulson)]

Lucas - The postinst script for dbus will attempt to start the service if it isn't already started (new installation) but will ask you to reboot if it is an upgrade

[James Westby (james-w)]

I don't think you do get a reboot prompt. Running with the existing dbus
until you next reboot is generally going to work.

> For what it's worth, I was able to reproduce this just now. Restart
> dbus, consolekit no-longer thinks I am logged in.

That's not what the bug is about though. Did you get repeated
messages in syslog about not being able to acquire the name
"org.freedesktop.ConsoleKit"?

Thanks,

James

[WillDyson (will-dyson)]

I do not get the syslog spam about not being able to acquire the name "org.freedesktop.ConsoleKit". So that does look to be fixed.

I would like to point out that this bug is marked as a duplicate of #216511, where the issue definitely is that the console-kit session is not recovered after a dbus restart.

But since there seems to be a prevailing attitude that you should no-more expect your desktop to survive a dbus restart than you would expect it to survive an Xorg restart, I also want to make it clear that there is a package out there somewhere that restarted dbus as part of its upgrade. That is the problem I was tracking down when I subscribed to this bug report.

If I figure out what package did this, I'll file a new bug on it.

[James Westby (james-w)]

Hi,

I'm retitling this report to reflect the problem that you see now.

I'm not sure this will be fixed though.

Thanks,

James