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.

share|improve this question
    
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. – James T Snell May 9 '14 at 23:19
    
I can, that's why I said I could startx from therr – Evpok May 9 '14 at 23:30
    
Oh, I didn't connect that's what you meant by "a tty". Okay. Fair enough. Does your /var/log/syslog give any clues? – James T Snell May 9 '14 at 23:31
    
I did not see anything obvious. Did you think of something specific? – Evpok May 9 '14 at 23:40
    
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. – James T Snell May 10 '14 at 4:45
up vote 3 down vote accepted

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.

share|improve this answer
    
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. – blujay Nov 10 '14 at 8:16
    
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). – Zitrax May 23 '15 at 16:38

I had the same problem after upgrade from Ubuntu 13.10 to Ubuntu 14.04. I had also in .xsession-errors file the last line reading:

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

The problem was also in .cache/upstart directory. It had permissions drw------- - so I was not even able to go into it. I just added an execute bit, restarted X and it works now.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.