TLDR: because systemd replaces consolekit with logind, programs that depend on consolekit to determine which "session" they're in may fail to do so unless they are also built with systemd support and the relevant pam session lines are enabled. This causes several silent failures and may prevent your desktop from starting.
Possible Cause: If you're using systemd, you may have built some gnome components with systemd support. This _disables_ consolekit support on those components, hence failures when booting outside of systemd. Try rebuilding polkit-gnome and any other gnome components with systemd support. This makes them use systemd-logind instead of consolekit. I don't use my system without systemd, but I suspect that you also have to start dbus and the (HORROR) systemd-logind service. _Someone ought to write a systemd-logind init script for enterprising gentoo users_. As it doesn't accept any arguments, I expect that it's as easy as the _completely untested_ one I have attached. Have fun! I can't wait to hear the excitement on this list on that, haha - but logind, like udev, should be able to work without systemd, which is why ubuntu is considering it. - http://www.phoronix.com/scan.php?page=news_item&px=MTMyMDE === BEGIN ADVENTURES I just recently fixed some woes I was having with starting an X session from lightdm. I am also on systemd. I got similar errors to the top post, X logs ending with "server terminator successfully" immediately after I perform a login attempt. I _also_ noticed that my X server died every time I switched virtual terminals, and I was unable to go back. This started a painstaking process of blind debugging, following this path: 1) start Xorg manually. is successful. === Xorg === note: dies when I VT switch back. 2) start Xorg manually and run a program in it. is successful. === export DISPLAY=:0 Xorg & terminator === note: also dies when I VT switch back. I suspected that this had something to do with multiseat support. The idea was that my system "does something" when I VT switch, and I suspected that whatever it was killed my X. 3) start Xorg manually and run a session in it. is successful. === export DISPLAY=:0 Xorg & gnome-session --session=unity === notes: - unity downloaded from unity-gentoo overlay. - have not been able to completely emerge -uDNtv && emerge -ctav in a week or so, so I expected problems. - dies when I VT switch back - mounting external hard disks fail with "Not authorized to perform action" - changing settings on Network manager also failed. I expected there to be a login prompt, but no prompt appeared. I'd experienced "Not authorized to perform action" before. It was a message that I got from policykit. So I suspected that my programs were failing to connect to policykit. (Not really experienced with polkit). After reading some manual pages [1][2][3][4][5] in policykit, I prepared another test. [1] polkit(8) [2] pkaction(1) [3] pkcheck(1) [4] pkexec(1) [5] pkttyagent(1) 4) Try running the failing commands using pkcheck/pkexec. They still fail. /usr/share/polkit-1/actions contains a list of actions available to policykit. You can also get a list of actions by running "pkaction" I determined that the relevant policy kit action to mount hard disks was org.freedesktop.udisks2.filesystem-mount To test the mount command, I used pkcheck, then pkexec. pkcheck tries to perform a policykit action directly and reports success or failure based on exit status. It needs a policykit action name and the PID of the session. === pkcheck --action-id org.freedesktop.udisks2.filesystem-mount --process $(pgrep gnome-session) === pkcheck complains that Authorization requires authentication and -u wasn't passed. Upon passing -u, pkcheck then complains that no authentication agent was available. An authentication agent is the program that generates a popup requiring login. I found this part suspicious, so I tried to activate an authentication agent. 5) Try running the failing commands with a dummy authentication agent. They now succeed. policykit comes with a builtin authentication agent. pkcheck has a --enable-internal-agent option which automatically produces a password prompt. Alternatively, you can run pkttyagent --process PID_OF_SOME_BASH_SESSION in one terminal, and any pkexec'd commands in that terminal will produce a login prompt on the pkttyagent terminal. === pkcheck --action-id org.freedesktop.udisks2.filesystem-mount --process $(pgrep gnome-session) --enable-internal-agent --allow-user-interaction === A login prompt appears, asking me what username I wish to login as. This suggests that _policykit is working_, but _gnome's policykit agent_ isn't. 6) Try to do everything again after emerging polkit-gnome is emerged with systemd support. They now succeed. I still can't get lightdm to work (still recompiling stuff)... but gdm now works just fine, and now I have my desktop working. Note that your /etc/pam.d/system-auth and system-session are expected to have lines with pam_systemd rather than pam_ck_connector, as per Gentoo wiki on systemd. http://wiki.gentoo.org/wiki/Systemd might I add that unity looks marvelous on Gentoo.
systemd-logind
Description: Binary data
