I run systemd environment, so I unmerged openrc and sysvinit today. And KDM was surprised on reboot: kdm[12916]: Failed to execute shutdown command "/sbin/shutdown -r now" (and I suspect that other login managers would be surprised, too) Reproducible: Always Steps to Reproduce: Click Kickoff -> "Leave" -> "Restart" -> "Restart Computer" Actual Results: A log-out without reboot.
Which version?
Sorry, forgot that. KDM 4.10.5-r1.
I made a look at another distro (Chakra). It provides symlinks: /sbin/poweroff -> /usr/bin/systemctl /sbin/reboot -> /usr/sbin/systemctl /sbin/halt -> /usr/sbin/systemctl
Probably those symlinks should be managed by "eselect init". But it's not ready yet.
KDE 4.11 will have proper systemd-logind support. You can install the KDE 4.11 rc2 (4.10.97) available in kde overlay or wait until mid august when 4.11.0 hits the tree. *** This bug has been marked as a duplicate of bug 451954 ***
I'll reopen this since bug 451954 is marked resolved now, but I still see this error with KDE 4.11. * Found these USE flags for kde-base/kdm-4.11.1: U I - - consolekit : Enables support for authorization using consolekit - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml + + handbook : Enable handbooks generation for KDE4. - - kerberos : Add kerberos support + + pam : Add support for PAM (Pluggable Authentication Modules) - DANGEROUS to arbitrarily flip + + systemd : Enable use of systemd-specific libraries and features like socket activation or session tracking
Do you have the policykit use flag enabled on sys-apps/systemd?
Yes, these are my flags: [ebuild R ] sys-apps/systemd-208-r1:0/1 USE="acl cryptsetup filecaps firmware-loader gudev introspection kmod pam (policykit) python tcpd -audit -doc -gcrypt -http -lzma -openrc -qrcode (-selinux) {-test} -vanilla -xattr" ABI_X86="(64) -32 (-x32)" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" 0 kB
I tried renaming /sbin/reboot and /sbin/shutdown and then rebooting from the Kickoff menu; it worked fine. Somebody if going to have to trace the code here to figure out why your system is invoking those commands. It's not supposed to happen.
@Pavel +xattr -firmware-loader [ebuild R ] sys-apps/systemd-208-r2:0/1 USE="acl -audit cryptsetup -doc filecaps -firmware-loader -gcrypt gudev -http introspection kmod lzma -openrc pam (policykit) python -qrcode (-selinux) tcpd {-test} -vanilla xattr" ABI_X86="-32 (64) (-x32)" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" I didn't any rename of poweroff. But it works! But I did edit some units like dhcpcd.service, which wanted to restart my wifi during shutdown.target :(
Did you run etc-update? What's the contents of /usr/share/config/kdm/kdmrc?
Yes, I have nothing to etc-update. Currently I have RebootCmd and HaltCmd set to "systemctl reboot/poweroff" but if I comment these lines, the problem continues to exist (I just tested again).
Created attachment 372652 [details] kdmrc
(In reply to Pavel Volkov from comment #13) > Created attachment 372652 [details] > kdmrc Could you please test if it works with sys-apps/systemd-sysv-utils?
Yes, it does.
I guess we could add that as a dependency for kdm[systemd]?
Thanks for reporting This is fixed for ~amd64, ~x86 in cvs now. Please sync in some hours to get the changes. We need to get the keywords on arm, ppc and ppc64 restored to resolve this bug finally. + + 15 Mar 2014; Johannes Huber <johu@gentoo.org> +kdm-4.11.7-r1.ebuild: + DEPEND on sys-apps/systemd-sysv-utils to fix bug #479426. Thanks to Manuel + "Sput" Nickschas for the hint. +
(In reply to Michael Palimaka (kensington) from comment #16) > I guess we could add that as a dependency for kdm[systemd]? I think that is not a good idea, to do it this way. i use mostly stable except KDE and some media apps. I am also using systemd: [7] default/linux/amd64/13.0/desktop/kde/systemd * I did an eix-sync earlier this morning and emerged all changes. Now a "emerge -pv --update --newuse --deep world --with-bdeps=y" shows me this output: [ebuild U ~] sys-apps/util-linux-2.24.1-r2 [2.22.2] USE="cramfs ncurses nls pam%* suid udev unicode -bash-completion% -caps% -cytune% -fdformat% -python% (-selinux) -slang -static-libs {-test} -tty-helpers% (-crypt%*) (-ddate%) (-old-linux%) (-perl%)" PYTHON_SINGLE_TARGET="python2_7%* -python3_2% -python3_3%" PYTHON_TARGETS="python2_7%* python3_3%* -python3_2%" 0 kB [ebuild N ~] sys-apps/systemd-sysv-utils-208 2,328 kB [ebuild U ~] kde-base/kdm-4.11.7-r1:4/4.11 [4.11.7:4/4.11] USE="handbook pam systemd (-aqua) (-consolekit) -debug -kerberos" 0 kB [blocks B ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/systemd-sysv-utils-208) Total: 3 packages (2 upgrades, 1 new), Size of downloads: 2,328 kB Conflict: 1 block (1 unsatisfied) !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: sys-apps/util-linux:0 (sys-apps/util-linux-2.24.1-r2::gentoo, ebuild scheduled for merge) pulled in by >=sys-apps/util-linux-2.24.1-r2 required by (sys-apps/systemd-sysv-utils-208::gentoo, ebuild scheduled for merge) (sys-apps/util-linux-2.22.2::gentoo, installed) pulled in by (no parents that aren't satisfied by other packages in this slot) It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. You may want to try a larger value of the --backtrack option, such as --backtrack=30, in order to see if that will solve this conflict automatically. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. * Error: The above package list contains packages which cannot be * installed at the same time on the same system. (sys-apps/systemd-sysv-utils-208::gentoo, ebuild scheduled for merge) pulled in by sys-apps/systemd-sysv-utils required by (kde-base/kdm-4.11.7-r1::gentoo, ebuild scheduled for merge) (sys-apps/sysvinit-2.88-r4::gentoo, installed) pulled in by >=sys-apps/sysvinit-2.86-r6 required by (sys-apps/openrc-0.12.4::gentoo, installed) For more information about Blocked Packages, please refer to the following section of the Gentoo Linux x86 Handbook (architecture is irrelevant): http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by sys-apps/systemd-sysv-utils-208 # required by kde-base/kdm-4.11.7-r1[systemd] # required by kde-base/kdebase-meta-4.12.3 # required by @selected # required by @world (argument) =sys-apps/util-linux-2.24.1-r2 ~amd64 # required by kde-base/kdm-4.11.7-r1[systemd] # required by kde-base/kdebase-meta-4.12.3 # required by @selected # required by @world (argument) =sys-apps/systemd-sysv-utils-208 ~amd64 If i remember correctly, the systemd guide said to keep sys-apps/sysvinit installed. With this combination my PCs restarts und did shutdown without any problem. Makes also sense, since systemd-sysv-utils has no stable keyword, because of the dependecy to the unstable version of util-linux. The only correct solution seems to be to fix this problem on the right place, so sys-apps/systemd should depend on sys-apps/sysvinit OR sys-apps/systemd-sysv-utils kdm is IMHO the wrong place to fix this. So i would suggest to revert this change in kdm as it is a dependency problem in systemd.
(In reply to Frank Krömmelbein from comment #18) > I think that is not a good idea, to do it this way. > i use mostly stable except KDE and some media apps. > I am also using systemd: Mixing stable and testing keywords is not fully supported, exactly because of the sort of errors you ran in to. You should keyword the extra packages as described by portage in the error message. > The only correct solution seems to be to fix this problem on the right > place, so sys-apps/systemd should depend on sys-apps/sysvinit OR > sys-apps/systemd-sysv-utils > kdm is IMHO the wrong place to fix this. So i would suggest to revert this > change in kdm as it is a dependency problem in systemd. systemd does not depend on either of those things, while the default configuration of KDM does, so it should be clear where the dependency goes.
Please revert that dependency change. Rebooting works perfectly fine for me without sys-apps/systemd-sysv-utils installed. KDM should be making a dbus call to systemd-logind to reboot the system. It should not be invoking /sbin/reboot directly.
(In reply to Michael Palimaka (kensington) from comment #19) > (In reply to Frank Krömmelbein from comment #18) > > I think that is not a good idea, to do it this way. > > i use mostly stable except KDE and some media apps. > > I am also using systemd: > Mixing stable and testing keywords is not fully supported, exactly because > of the sort of errors you ran in to. You should keyword the extra packages > as described by portage in the error message. If it would have been so easy, I would not have written here. I have added the two entrys and also for sys-apps/systemd, here is what happend: [nomerge ] kde-base/kdebase-meta-4.12.3:4 USE="wallpapers (-aqua)" [nomerge ] kde-base/ksmserver-4.11.7:4/4.11 USE="(-aqua) -debug" [ebuild U ~] kde-base/kdm-4.11.7-r1:4/4.11 [4.11.7:4/4.11] USE="handbook pam systemd (-aqua) (-consolekit) -debug -kerberos" 0 kB [ebuild N ~] sys-apps/systemd-sysv-utils-208 0 kB [ebuild U ~] sys-apps/util-linux-2.24.1-r2 [2.22.2] USE="cramfs ncurses nls pam%* suid udev unicode -bash-completion% -caps% -cytune% -fdformat% -python% (-selinux) -slang -static-libs {-test} -tty-helpers% (-crypt%*) (-ddate%) (-old-linux%) (-perl%)" PYTHON_SINGLE_TARGET="python2_7%* -python3_2% -python3_3%" PYTHON_TARGETS="python2_7%* python3_3%* -python3_2%" 0 kB [nomerge ] sys-apps/openrc-0.12.4 USE="ncurses netifrc pam unicode -debug -newnet (-prefix) (-selinux) -static-libs -tools" [ebuild N ] sys-apps/sysvinit-2.88-r4 USE="(-ibm) (-selinux) -static" 0 kB [blocks B ] <sys-apps/sysvinit-2.88-r7 ("<sys-apps/sysvinit-2.88-r7" is blocking sys-apps/util-linux-2.24.1-r2) [blocks B ] >=sys-apps/util-linux-2.23 (">=sys-apps/util-linux-2.23" is blocking sys-apps/sysvinit-2.88-r4) [blocks B ] sys-apps/sysvinit ("sys-apps/sysvinit" is blocking sys-apps/systemd-sysv-utils-208) And: equery d sysvinit * These packages depend on sysvinit: sys-apps/openrc-0.12.4 (kernel_linux ? >=sys-apps/sysvinit-2.86-r6) sys-apps/systemd-208-r3 (<sys-apps/sysvinit-2.88-r4) So how to solve that gordian knot? > systemd does not depend on either of those things, while the default > configuration of KDM does, so it should be clear where the dependency goes. Ok. But then please change the new kdm Ebuild so that sys-apps/sysvinit OR sys-apps/systemd-sysv-utils is sufficient. It works for months for me with that configuration.
(In reply to Frank Krömmelbein from comment #21) > But then please change the new kdm Ebuild so that sys-apps/sysvinit OR > sys-apps/systemd-sysv-utils is sufficient. > > It works for months for me with that configuration. Again, this dependency is unnecessary and should be dropped completely. The only person having a problem is Pavel Volkov. For the rest of us, the systemd-logind support works fine.
(In reply to Mike Gilbert from comment #22) > (In reply to Frank Krömmelbein from comment #21) > > But then please change the new kdm Ebuild so that sys-apps/sysvinit OR > > sys-apps/systemd-sysv-utils is sufficient. > > > > It works for months for me with that configuration. > > Again, this dependency is unnecessary and should be dropped completely. > > The only person having a problem is Pavel Volkov. For the rest of us, the > systemd-logind support works fine. It was a mid air collision ;-) I had already given up that such a proposal comes from a Dev ;-)
I can third that this dependency change causes more problems than fixes. Both openrc AND systemd depend on sysvinit (and not sys-apps/systemd-sysv-utils). I too arrive at this: equery d sysvinit * These packages depend on sysvinit: sys-apps/openrc-0.12.4 (kernel_linux ? >=sys-apps/sysvinit-2.86-r6) sys-apps/systemd-208-r3 (<sys-apps/sysvinit-2.88-r4) So if we're making kdm depend on systemd-sysv-utils, they should probably fix the dependency in systemd to be either/or... and I personally still haven't been able to get openrc removed without it being forced back in, but that's another story. But systemd and kdm should at least have the same dependencies when it comes to sysvinit, I would think. :)
openrc is in base/packages (aka the "system" set), pending a fix for bug 373219 (which may take quite some time if the route taken is "change everything currently sourcing /etc/init.d/functions.sh to source /lib/gentoo/functions.sh instead"). Unmerging openrc is currently not a good idea for most people, even those already on systemd. For systemd users, the current expected situation is to have systemd, sysvinit and openrc installed. They can coexist peacefully, with most of sysvinit and openrc not running if systemd is in use. Once removing sysvinit and openrc becomes actually possible/supported, I'd expect a virtual to get added to packages/base ("system") to make sure everyone has either sysvinit or systemd-sysv-utils (to provide "shutdown" and friends). The situation described in comment #0 of this bug (no package installed providing /sbin/shutdown) should therefore be impossible, without kdm needing explicit dependencies to ensure it. If kdm really does depend on systemd-sysv-utils, that is surprising. Are you sure kdm still breaks if systemd is in use with sysvinit installed instead of systemd-sysv-utils?
(In reply to Marien Zwart from comment #25) Bug 373219 is fixed and the they decided on the route you said. Previously I removed openrc from @system set with /etc/portage/profile/packages. Now I tested again this way: 1. Brought openrc back to @system. 2. Temporarily renamed /sbin/shutdown. And the problem still remains. I'll rename the bug to better indicate make it more precise.
Please revert this change immediately. kdm now requires systemd-sysv-utils. systemd-sysv-utils blocks sysvinit. openrc depends on sysvinit. openrc is a system package. openrc-less systems are not yet supported by Gentoo. Thus this dependency makes no sense. Revert immediately please. I also am unable to reproduce this problem. The latest KDE supports calling systemd through dbus calls for shutdown. It should not be execing to those programs anyway. Thus this patch does not even solve its intended purpose in the correct way. Please revert.
(In reply to Matthew Graybiel from comment #24) > I can third that this dependency change causes more problems than fixes. > Both openrc AND systemd depend on sysvinit (and not > sys-apps/systemd-sysv-utils). I too arrive at this: > > equery d sysvinit > * These packages depend on sysvinit: > sys-apps/openrc-0.12.4 (kernel_linux ? >=sys-apps/sysvinit-2.86-r6) > sys-apps/systemd-208-r3 (<sys-apps/sysvinit-2.88-r4) Just to be clear, systemd depends on: || ( >=sys-apps/util-linux-2.22 <sys-apps/sysvinit-2.88-r4 ) so the preferred solution is to upgrade util-linux.
+ 16 Mar 2014; Michael Palimaka <kensington@gentoo.org> -kdm-4.11.7-r1.ebuild: + Remove revision bump causing issues wrt bug #479426.
Given that nobody else can reproduce, I can only assume that it is some other issue with system system beyond mixing keywords and removing packages from @system. Given that kdm does not appear to interface with systemd directly, there is no new development of kdm, and kdm will be completely removed in the next major release, there's nothing we can do.
Ah, it seems I misunderstood what KDM was doing here; it has no native support for calling systemd-logind. It calls /sbin/shutdown, even on systemd systems. So long as KDM is running as root, this should (and does) work with either sys-apps/sysvinit or sys-apps/systemd-sysv-utils.
(In reply to Pavel Volkov from comment #26) > (In reply to Marien Zwart from comment #25) > Bug 373219 is fixed and the they decided on the route you said. I should have said "bug 373219 and bug 504116". Until most bugs linked from that tracker are also fixed, just removing openrc will break things (some core packages depend on /etc/init.d/functions.sh). > Previously I removed openrc from @system set with > /etc/portage/profile/packages. If you make modifications such as this, please mention them when filing bugs. > Now I tested again this way: > 1. Brought openrc back to @system. > 2. Temporarily renamed /sbin/shutdown. If you make modifications such as this, please mention them when filing bugs.
> If you make modifications such as this, please mention them when filing bugs. Sorry, I mentioned in the original bug title that openrc is not installed. I thought it would be clear that I uninstalled it.
