[Bug 331002] New: PolicyKit denies suspend sometimes
https://bugzilla.novell.com/show_bug.cgi?id=331002 Summary: PolicyKit denies suspend sometimes Product: openSUSE 10.3 Version: Final Platform: i686 OS/Version: openSUSE 10.3 Status: NEW Severity: Critical Priority: P5 - None Component: Mobile Devices AssignedTo: behlert@novell.com ReportedBy: tremonium2100@gmx.de QAContact: qa@suse.de Found By: --- I use a Dell Latitude D620 notebook and suspend worked out of box at first. But then I could not suspend my device anymore as normal user. Suspending as root still worked. I "solved" the bug by adding a config-file to /etc/pm/config.d with the line S2RAM_OPTS="-f -p -m". I later removed this file and suspend still worked. Then it stopped working again and after rebooting worked again without me changing anything. While suspend not working, "suspend -u" declared that PolicyKit denied suspend (I do not have the correct output, because it works by now). Pressing the suspend-buttons KPowersave stated "Suspend to disk disabled by administrator.". What also came to my attention is, that if suspend does not work, KPowersave offers me to change the brightness. If suspend works the option to change brightness is greyed out. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002
Timo Hoenig
https://bugzilla.novell.com/show_bug.cgi?id=331002
Timo Hoenig
https://bugzilla.novell.com/show_bug.cgi?id=331002#c1
Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c2
Peter Kreussel
https://bugzilla.novell.com/show_bug.cgi?id=331002#c3
Danny Kukawka
Hmm, works for me. Danny?
Never seen something like that, works for me too. Can only assume here some problems in PolicyKit or ConsoleKit atm. (In reply to comment #0 from Daniel Rose)
Suspending as root still worked. I "solved" the bug by adding a config-file to /etc/pm/config.d with the line S2RAM_OPTS="-f -p -m". I later removed this file and suspend still worked. Then it stopped working again and after rebooting worked again without me changing anything.
Don't change something in the pm config, this has absolutely nothing to do with your problem!
While suspend not working, "suspend -u" declared that PolicyKit denied suspend (I do not have the correct output, because it works by now).
We can't do anything without the correct error message. You should also check the state of hal (work lshal) and consolekit (rcconsolekit status). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c4
--- Comment #4 from Peter Kreussel
https://bugzilla.novell.com/show_bug.cgi?id=331002#c5
--- Comment #5 from Peter Kreussel
https://bugzilla.novell.com/show_bug.cgi?id=331002#c6
--- Comment #6 from Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c7
Danny Kukawka
You need to log out and in again after starting consolekit for the changes to take effect.
BTW.: Did you do an update?
@Holger: Due to his last comment I would assume he did a clean install. This all looks to me as if we have a general problem with get ConsoleKit running on boot. The strange is: I have seen this never on one of my test machines with GM. I saw this only as we introduced the new HAL/policyKit/ConsoleKit the first time while beta. We should think about put all the ConsoleKit bugs together to two bugs: one for the update from 10.2 to 10.3 and one for clean 10.3 install. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c8
--- Comment #8 from Peter Kreussel
You need to log out and in again after starting consolekit for the changes to take effect.
I see. So that happens when and only when consolekit is not running.
BTW.: Did you do an update?
No, I did a clean install into an empty partition. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c9
--- Comment #9 from Daniel Rose
https://bugzilla.novell.com/show_bug.cgi?id=331002#c10
--- Comment #10 from Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c12
--- Comment #12 from Peter Kreussel
https://bugzilla.novell.com/show_bug.cgi?id=331002#c16
Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c17
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c18
Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c19
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c20
--- Comment #20 from Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c21
--- Comment #21 from Holger Macht
How would startproc wait and know until D-Bus is fully initialized?
Having D-Bus fork itself sounds right, the D-Bus init script will not return until the daemon is running properly, and no dependency will start earlier.
If D-Bus forks, the init script returns _before_ D-Bus is up and running. I think starproc behaviour without any options is to start all processes asyncronous. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c22
--- Comment #22 from Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c23
--- Comment #23 from Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c24
--- Comment #24 from Martin Wilck
That would be a silly bug in D-Bus, to fork before complete init. Did you see this, or are you guessing?
We saw it. That's what this bug is all about. It's easy to verify with the "invalid user gdm" problem, at least on my system. With the current OpenSUSE packages, the warning comes _after_ the rc script is finished: # rcdbus start starting DBUS services ... Done [ warning message about gdm user ] Using my proposal from comment #18: # rcdbus start starting DBUS services... [ warning message about gdm user ] Done Note that this is an SMP (Core-2) system. wrt comment #20:
How would startproc wait and know until D-Bus is fully initialized?
Of course startproc does not know if dbus is 100% initialized yet. But there is a difference because now startproc itself does the daemonizing. Do be 100% sure, a test for working dbus services must be added after the startproc in /etc/init.d/dbus, with a wait loop if the service isn't there yet. I don't know how to write such a test though. Perhaps a test for exisitence of the dbus socket is sufficient. But that needs to be checked by dbus experts. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c25
--- Comment #25 from Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c26
--- Comment #26 from JP Rosevear
(In reply to comment #22 from Kay Sievers)
That would be a silly bug in D-Bus, to fork before complete init. Did you see this, or are you guessing?
We saw it. That's what this bug is all about.
As Holger says, it appears to be actually that startproc exits immediately, it daemonizes the *parent* process immediately and doesn't wait for it to exit normally. If it did dbus really would be all setup. As Kay pointed out to me: startproc /bin/sleep 5 - it exits immediately, not after 5 seconds.
It's easy to verify with the "invalid user gdm" problem, at least on my system.
With the current OpenSUSE packages, the warning comes _after_ the rc script is finished:
# rcdbus start starting DBUS services ... Done [ warning message about gdm user ]
Using my proposal from comment #18:
# rcdbus start starting DBUS services... [ warning message about gdm user ] Done
Note that this is an SMP (Core-2) system.
wrt comment #20:
How would startproc wait and know until D-Bus is fully initialized?
Of course startproc does not know if dbus is 100% initialized yet. But there is a difference because now startproc itself does the daemonizing.
Do be 100% sure, a test for working dbus services must be added after the startproc in /etc/init.d/dbus, with a wait loop if the service isn't there yet. I don't know how to write such a test though. Perhaps a test for exisitence of the dbus socket is sufficient. But that needs to be checked by dbus experts.
If so startproc is worse than useless here and we should just eliminate it like was done for 11.0 as per bug 332845. It seems startproc is more for things that don't do their own daemonization properly. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c27
--- Comment #27 from Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c28
--- Comment #28 from Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c29
--- Comment #29 from Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c30
--- Comment #30 from Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c31
--- Comment #31 from Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c32
--- Comment #32 from Martin Wilck
https://bugzilla.novell.com/show_bug.cgi?id=331002#c33
--- Comment #33 from JP Rosevear
What are you trying to tell me with this trace? The "Failed to connect to socket: No such file or directory" messages are there, and they indicate pretty clearly that it's possible that console-kit-daemon starts before the socket is created.
Its a trace of starting dbus without startproc. It shows that the socket is setup and pid file is written before dbus exits if startproc is *not* used. If startproc is used, you get the error. As per bug 332845, replacing the startproc line with just: $DBUS_DAEMON_BIN $DBUS_DAEMON_PARAMETER should fix it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=331002#c37
Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c38
Kay Sievers
https://bugzilla.novell.com/show_bug.cgi?id=331002#c43
Danny Kukawka
https://bugzilla.novell.com/show_bug.cgi?id=331002#c46
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c47
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c48
--- Comment #48 from flo gleixner
https://bugzilla.novell.com/show_bug.cgi?id=331002#c49
--- Comment #49 from flo gleixner
https://bugzilla.novell.com/show_bug.cgi?id=331002#c50
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c58
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c59
Holger Macht
https://bugzilla.novell.com/show_bug.cgi?id=331002#c60
Harald Mueller-Ney
https://bugzilla.novell.com/show_bug.cgi?id=331002#c61
Danny Kukawka
https://bugzilla.novell.com/show_bug.cgi?id=331002
User dkukawka@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=331002#c62
--- Comment #62 from Danny Kukawka
participants (1)
-
bugzilla_noreply@novell.com