Unable to start kde

Question

Rebooting my laptop after a few days of uptime (so I don't know what could have triggered the issue) I have found that I am unable to login from lightdm. My password is accepted and the fields disappear but I am stuck with the lightdm wallpaper and my (movable) cursor. I can however

• login as guest
• startx from a tty

If I try from kdm, the same thing happens.

If I try to launch project-neon, the desktop progressbar appear, but I am thrown back to lightdm wallpaper when it is done loading, also a prompt for keyring password appeared, and after entering it, the desktop briefly flashed in.

.xsession says that dbus pre-start process terminated with status 2. I don't know if it is relevant.

Edit: I am able to launch lxde without issues. I have tried plasma-active, I have the same symptoms as with project-neon so clearly this is a kde/plasma issue. But since starting from startx works, the issue seem to lie in lightdm/kdm-kde interactions. Is there a way to track how lightdm starts kde (kwin, plasma)?

Also the issue is not with login, the graphical session appears in who and dm-tool list-seats shows a Session0 with my username.

Edit: I have tried a few more things. I mentionned a password prompt in project-neon. If I let it sit for a moment, the desktop eventually appears and works.

I have also tried adding debug outputs to startkde and startactive. Those in startactive work but not those instartkde (when starting from lightdm or kdm, but it works from xinit /usr/bin/startkde) so it may be that lightdm doesn't even start startkde, though it does according to lightdm.log.

Solution

TL;DR there was a permission issue with ~/.cache/upstart/dbus-session, rm -rf .cache/upstart and a reboot solved it.

Newbie debug insights for future readers (which may well include me).

The ~/.xsession message I mentioned in the question, along the lines of

init: dbus pre-start process (PID XXXX) terminated with status 2

was actually very important. I learnt what it meant while investigating, I found it this way

• First, I thought that the issue was with kde, so I tried to find how lightdm started kde
• I tried to look into /etc/lightdm/ (as suggested by man lightdm) but the lightdm config files were not here but (I found it by looking into /var/log/lightdm.log) in /usr/share/lightdm/lightdm.conf.d where I found the relevant file /usr/share/lightdm/lightdm.conf.d/40-kde-plasma.conf
• According to it, what lightdm started for kde was the script /usr/bin/startkde, so I added some debug echo 'startkde is at line ##' > /home/evpok/delog lines to it to see where it failed, but none of them were executed.
• checking again /var/log/lightdm.log I saw the line
  Running command /usr/sbin/lightdm-session /usr/bin/startkde
  so I looked into usr/sbin/lightdm-session, to which I again added debugging echo lines
• After some fumbling, I found that the issue was with loading an Xsession script: /etc/X11/Xsession.d/99x11-common_start. So I looked into that one. It seemed to load normally and had only one line exec $STARTUP. Adding an echo to see what was in $STARTUP I found it was init --user. Now I didn't want to mess with init so I just traced its outputs by commenting this line out and adding instead
  exec init -v --user > /home/evpok/initlog 2> /home/evpok/initerrlog

• Looking into these logs, I saw this message in initerrlog

  dbus pre-start process (PID XXXX) terminated with status 2
  but I still didn't know what to make of it, so I looked into initlog and saw
  Loading configuration from /usr/share/upstart/sessions

• I looked into that dir, where I saw a startkde.conf. After some looking into documentation for upstart job confs, I saw that it had
  start on started dbus and xsession SESSION=kde-plasma
  obviously that was why startkde didn't start. It needed dbus, which had an error, so I looked into dbus.conf
• There, there was a pre-start script stanza, hey! That's what's in the errlog of init and in .xsession-errors. So for I added again some echoes, to find that the issue was at the line
  echo "DBUS_SESSION_BUS_ADDRESS=${DBUS_SESSION_BUS_ADDRESS}" >$HOME/.cache/upstart/dbus-session (Not one of my debug echoes)
• After some fumbling, I found that I couldn't touch the non-existent file ~/.cache/upstart/debus-session because of a permission issue. I tried creating it under sudo and chown it to me with appropriate permissions but it didn't work. So I just rm -rf'ed .cache/upstart.
• After a reboot, everything worked as expected.

After all I just needed to stop being afraid of the internals and getting my hands dirty.

Comments

[user2058205]

Can you login at the console? Pretty ctrl+alt+f1 to get one. If you can't login there, it's probably a PEBKAC. Press ctrl+alt+f7 to get back to the gui.

[Evpok]

I can, that's why I said I could startx from therr

[user2058205]

Oh, I didn't connect that's what you meant by "a tty". Okay. Fair enough. Does your /var/log/syslog give any clues?

[Evpok]

I did not see anything obvious. Did you think of something specific?

[user2058205]

Not sure where I'd go next. I'd wager it's a configuration matter. You could rule-out a hardware issue by booting from a USB installer, but it doesn't seem like a hardware issue anyway. I assume your software is fully up to date? Does your /etc/X11/xorg.conf contain anything? Maybe rename your xorg.conf, if it does have anything in it, this will force Xorg to improvise, which could be an improvement.

[Evpok]

What bugs me is that a guest session works, so it should be specific to mine. Are there session-specific xorg settings somewhere?

[Rishikesh Chapekar]

You just saved me so much time and hair-pulling. After 83 days of uptime, I rebooted and couldn't get into KDE. I did nothing to cause this problem. All I did was install the usual upgrades to packages. It's absolutely nuts how much you had to do to dig down to the stupidly simple problem, and that would have been me if you hadn't shared this. Thank you. BTW, there needs to be a bug filed on Launchpad about this. I don't know what could have caused it, but it's really messed up that there's no simple log message in ~/.xsession-errors or /var/log/lightdm about the permission problem.

[Zitrax]

I don't really know if my problem was the same but deleting .cache solved the issue for me too (worked fine also without rebooting).