I can no longer shut down my laptop from the KDE menu after upgrading to sys-auth/consolekit-1.0.1 - the shutdown button is not displayed. Downgrading to sys-auth/consolekit-1.0.0-r1 fixes the issue. Using KDE 5.5.2 Reproducible: Always
Created attachment 422966 [details] emerge --info
Bisected. Looks like it's caused by that commit: https://github.com/ConsoleKit2/ConsoleKit2/commit/ac39c4ea6bc0b5649c2389548fb27bc32668199b Can anyone else reproduce? Should I take it upstream?
I haven't heard about this bug yet so far, but upstream is very responsive and will surely appreciate your bisection.
I can confirm this on my laptop too, no shutdown and reboot buttons is displayed. Using plasma-5.5.3, upower-0.99.2-r1, no systemd. Downgrading to consolekit-1.0.0-r1 fixes the issue.
Thanks guys! I reported it upstream, let's see if they have any ideas.. https://github.com/ConsoleKit2/ConsoleKit2/issues/58
you're using sddm as the login manager? is the env var that the bisected commit checks wrong on your machine somehow? (once you're logged in, run "env | grep XDG_") Also, there was another change introduced in 1.0.1, can you remove /usr/lib/ConsoleKit/run-session.d/pam-foreground-compat.ck and see if that makes any difference? that file does not exist in the 1.0.0 ebuild.
Yes, I'm using sddm-0.13.0-r1. XDG_VTNR seems to be set and correct (ctrl-alt-f7 shows the desktop): $ env | grep XDG_VTNR XDG_VTNR=7 Removing pam-foreground-compat.ck does not have any effect. I would try to debug it more myself, but I'm not sure where to start.. any hints about which processes/methods are relevant are appreciated :)
Created attachment 423306 [details] ck-list-sessions + console-kit-daemon debug log Ok, I debugged plasmashell, console-kit-daemon and polkitd a bit: * plasmashell asks console-kit-daemon "CanStop" which returns false. * console-kit-daemon decides that by asking polkitd * polkitd decides by asking console-kit-daemon about the session * console-kit-daemon says the session is local, but not active Running ck-list-sessions shows that there are two sessions for my user (why?) and only one of them is active. After enabling debug logging, syslog shows that plasmashell is checking CanStop for the inactive session. Logs attached.
I had built sddm with USE="consolekit". Building with USE="-consolekit" fixes the issue for me: I no longer have two sessions and the one I have is active. As far as I understand, consolekit's pam integration opens a session automatically on login and before I had sddm open one, too. Maybe add a warning to sddm ebuild about the use flag and potential breakage? I think this bug can be closed or transformed into a sddm ebuild issue.
Please check: grep pam_ck_connector /etc/pam.d/system-login
pam_ck_connector seems to be working fine for me. the problem was duplicate sessions opened by sddm? $ grep pam_ck_connector /etc/pam.d/system-login session optional pam_ck_connector.so
It seems you have removed the trailing 'nox11' from that line at some point in the past, as described by the sddm wiki in case of trouble - not a good advice these days anymore, imo. Could you try again with that file fixed, and sddm[consolekit]?
tested: nox11 + sddm[consolekit] works ok, only one session and it is active.
So, sddm now has a check for erroneous system-login config: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=448091cb54719cb8c1bb02466dbb4051a10fff0b And the wiki was updated: https://wiki.gentoo.org/wiki/KDE/Plasma_5_upgrade#Missing_shutdown.2C_reboot.2C_suspend_and_hibernate_buttons_when_using_OpenRC
thanks! that could help the next guy stepping on the same issue :) on the same topic: it seems rather easy to forget the sddm[+consolekit] flag and wonder why the session is broken. it isn't enabled by default or pulled in by anything i have installed. but this bug might not be the best place to bring it up..
That really only is a problem for non-plasma-profile users - it's expected you're a bit more on your own there. Not sure what more could be done than that, I just checked and it is already part of the consolekit guide: https://wiki.gentoo.org/wiki/ConsoleKit#USE_flags
didn't know about the desktop profiles. if most people use these then i suppose it's fine. thanks for the info!
How about introducing a systemd USE flag to plasma-meta to enforce a dependency on sddm[consolekit] when unset?
*** Bug 573138 has been marked as a duplicate of this bug. ***
Sorry to comment on a closed bug, but I *think* this is related. I came here from my own bug 573138, that happened to be a duplicate. After re-adding the "nox11" option to the pam_ck_connector, and removing/re-adding the K-Menu, I got the shutdown and reboot buttons and options back. So that fix worked. *BUT* : I no longer can suspend my laptop. I no longer have the option, powerdevil does no longer offer me to suspend the laptop on lid close, and my laptops hotkey (Fn+F1) only blanks the screen for a few seconds before showing the desktop again. This is very bad. Suspension works if I use "sudo hibernate-ram" from a console, and it worked before the "fix". Any ideas on how to debug this?
Found it. After the removal of sys-power/upower-pm-utils nothing needed pm-utils any more and the next --depclean removed it. A USE flag should be added to sys-auth/consolekit to pull it in instead of just displaying an information about pm-utils being needed. The powerdevil/consolekit/upower upgrade went through with pm-utils installed, so no warning or information came.
(In reply to Sven Eden from comment #21) > Found it. > > After the removal of sys-power/upower-pm-utils nothing needed pm-utils any > more and the next --depclean removed it. > > A USE flag should be added to sys-auth/consolekit to pull it in instead of > just displaying an information about pm-utils being needed. The > powerdevil/consolekit/upower upgrade went through with pm-utils installed, > so no warning or information came. alas USE-flags are not supposed to control optional runtime deps that are not needed at build time. Not everyone wants to suspend and flipping the useflag would mean rebuilding the entire package when literally nothing changed. I dont really like the policy personally but such is life :(.
(In reply to Michael Palimaka (kensington) from comment #18) > How about introducing a systemd USE flag to plasma-meta to enforce a > dependency on sddm[consolekit] when unset? Beware of users that want to have neither systemd nor consolekit. ;)
(In reply to Jason Zaman from comment #22) > (In reply to Sven Eden from comment #21) > > Found it. > > > > After the removal of sys-power/upower-pm-utils nothing needed pm-utils any > > more and the next --depclean removed it. > > > > A USE flag should be added to sys-auth/consolekit to pull it in instead of > > just displaying an information about pm-utils being needed. The > > powerdevil/consolekit/upower upgrade went through with pm-utils installed, > > so no warning or information came. > > alas USE-flags are not supposed to control optional runtime deps that are > not needed at build time. Not everyone wants to suspend and flipping the > useflag would mean rebuilding the entire package when literally nothing > changed. I dont really like the policy personally but such is life :(. Sorry, that made me rather angry yesterday, so I waited until today. 1) I thought that is what RDEPEND is supposed to be for. If only that changes, a package does not need to be rebuilt. If portage can not handle it, it should be included. 2) There are other USE flags, like "doc" that trigger a full rebuild although it is not necessary. So? Remove that flag from almost every package? 3) I can understand all this, but pm-utils would be a USE flag you either set once, because you have a mobile device, or do not set anyway, because you do not need it. 4) Hiding this in an einfo message broke stuff for me, because emerge --depclean removed pm-utils, that was pulled in by upower-pm-utils. Am I the only one who got their pm-utils package removed, because an einfo message told them, that upower-pm-utils is no longer needed? I hope so. (The ugly thing about 4 is, that at the time consolekit got updated, it was in the wake of the change to upower. At that time, pm-utils was still there, so consolekit did not issue any message.)
(In reply to Sven Eden from comment #24) > (In reply to Jason Zaman from comment #22) > > (In reply to Sven Eden from comment #21) > > > Found it. > > > > > > After the removal of sys-power/upower-pm-utils nothing needed pm-utils any > > > more and the next --depclean removed it. > > > > > > A USE flag should be added to sys-auth/consolekit to pull it in instead of > > > just displaying an information about pm-utils being needed. The > > > powerdevil/consolekit/upower upgrade went through with pm-utils installed, > > > so no warning or information came. > > > > alas USE-flags are not supposed to control optional runtime deps that are > > not needed at build time. Not everyone wants to suspend and flipping the > > useflag would mean rebuilding the entire package when literally nothing > > changed. I dont really like the policy personally but such is life :(. > > Sorry, that made me rather angry yesterday, so I waited until today. > > 1) I thought that is what RDEPEND is supposed to be for. If only that > changes, a package does not need to be rebuilt. If portage can not handle > it, it should be included. > > 2) There are other USE flags, like "doc" that trigger a full rebuild > although it is not necessary. So? Remove that flag from almost every package? > > 3) I can understand all this, but pm-utils would be a USE flag you either > set once, because you have a mobile device, or do not set anyway, because > you do not need it. bug 557432#c2 has where it originally came up. The official line comes from: https://devmanual.gentoo.org/general-concepts/use-flags/ "The usage of a USE flag should not control runtime dependencies when the package does not link to it. Doing so will create extra configuration for the package and re-compilation for no underlying file change on disk. This should be avoided and instead can be conveyed to the user via post install messages if needed." I am going to add the pm-utils flag back. I think there is sufficient justification to have the flag and CK is a small enough package that rebuilding is not a big deal.
Reopening to make sure updating the powerdevil side is not forgotten.
(In reply to Michael Palimaka (kensington) from comment #26) > Reopening to make sure updating the powerdevil side is not forgotten. Fixed in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d4ccaaa1b5b79672ff112936ed52f07be89b0442 https://gitweb.gentoo.org/proj/kde.git/commit/?id=fcc7b0d15a3f357fd104ae84dabcb9f5490af36f
