Can anyone help me please? KDE 4.8 broke power management for me on my ASUS notebook. Checking the forums, all I could find was similar problems that went away either with reinstalling stuff or the next release. But my problems remain on KDE 4.9.5 etc.

Shutting the lid causes some disk activity, but doesn't hibernate the system, though KDE power management is configured to do that. Neither hibernate nor suspend work from KDE menus, but pm-hibernate and pm-suspend work fine from root command line.

recompiling for gdb, rebooting and attaching to the first polkitd process lets me see a backtrace, though it's not a lot of use, as I think the segfault is in the javascript interpreter used to process the policy rules. In summary, the backtrace shows:

I note that it says subject_is_active=0; this is before I've logged into KDE. I'm surprised there's anything to do with suspend going on yet.

When I log in, ck_list_sessions shows one session for me active and local, though interestingly with no login session id.
FWIW, udisks --mount works for me. upower -d shows mostly what I'd expect, except the Daemon entries are all "no", even though I'm on battery, and should be able to suspend and hibernate.
I tried playing with policy settings in the KDE System Settings - Actions Policy, but changes to e.g org.freedesktop.upower.suspend result in org.freedesktop.DBus.Error.AccessDenied, with details Unknown reply from QPolkit-1, Error GDBusError.org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus).

This is a standard KDE desktop, using stable stuff almost everywhere, and AFAIR no changes to Polkit, ConsoleKit, Pam, DBus, udev, or whatever. No sign of systemd.
[/update]

I've no idea what. if anything, any of this means!
(I assume the breakage is down to KDE changes to support systemd. I'm still using openrc & udev, but AFAIK so are most Gentoo KDE users.)_________________Greybeard

Last edited by Goverp on Tue May 28, 2013 12:09 pm; edited 1 time in total

Backtraces show (as above) that the the polkit daemon repeatedly dies due to a segfault in the spidermonkey javascript engine used by policykit. At the point of failure, spidermonkey is being used to run a rule asynchronously with a timeout. That shouldn't cause a segfault, of course.

Comparing my laptop, which shows the fault, with my desktop, which doesn't, a few significant differences:

1) The successful system's polkit startup goes on to the message "Acquired the name org.freedesktop.PolicyKit1 on the system bus" in syslog at the point where the failing system hits the segfault.

2) A polkit bug report at https://bugzilla.redhat.com/show_bug.cgi?id=834494 suggests diagnosis by restarting polkitd. When I do that, it acquires the name correctly, but then issues the message "WARNING ***: skipping unknown tag <i> at line 336", as per the bug report. The bug report goes on to suggest the authentication client behind polkit (I assume consolekit) is timing out.

3) The consolekit daemon is in the default runlevel, and active, and its log in /var/log/ConsoleKit/history has no signs of anything going wrong.
ck-list-sessions output for both is the same except the failing system has "login-session-id = ''", whereas the successful one has a numeric id.

Can anyone point me at a suggestion as how to proceed? I've spent ages Googling this problem - lots of hits, but most of them are either full of misguided half-assed guesswork, or use the Windows default solution (i.e. reinstall everything in sight).

Maybe I should just remove all software "*Kit". Given the appalling & unnecessary complexity. lack of documentation and ability of anyone to debug the mess... _________________Greybeard

I revisited this problem, and found some gnome users suffering from spidermonkey segfaulting. Their fix was to recompile bits of gnome and spidermonkey with all optimizations off. As my problem is on an Intel Atom-powered netbook and I use -O3, I tried recompiling spidermonkey without optimization, but that didn't work. Recompiling both it and polkit did fix the segfaults, and now polkitd stays around, and hibernation, suspend, and network manager all work. Some time, I'll try bisecting to see which optimizations on what actually fix the issue. As for now, my fix was to add lines to /etc/portage/package.env