What causes the 'Failed to start session' error on Ubuntu 14.04?

Question

Yesterday when I turned on my home laptop I got the 'Failed to start session' error and could not log in. I was only able to fix this today, searching for a solution at the office. I was effectively locked out of my laptop for more than 24 hours; in over 5 years of Ubuntu this was the most serious situation I experienced.

The original question here at AskUbuntu refers to a failed upgrade, but I ran into this problem months after upgrading to 14.04. There were no relevant package upgrades in the previous session to justify such a failure.

What is exactly causing this problem? And how can I avoid running into it again in the future?

Update: Some forensic data: a new kernel image was installed on the 15th (linux-image-extra-3.13.0-34), but I was able to log on and work normally on the following day. It was on the 17th that the session started to failed, so whatever caused this problem happened on the 16th. Here's the àptdaemon log from that day:

Start-Date: 2014-08-16  08:54:23
Commandline: aptdaemon role='role-commit-packages' sender=':1.100'
Upgrade: subversion:amd64 (1.8.8-1ubuntu3, 1.8.8-1ubuntu3.1), libnepomukcleaner4:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), libsystemd-login0:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), systemd-services:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libbalooxapian4:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), nepomuk-core-data:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), libsystemd-daemon0:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libgudev-1.0-0:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libpam-systemd:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libsvn1:amd64 (1.8.8-1ubuntu3, 1.8.8-1ubuntu3.1), udev:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), gir1.2-gudev-1.0:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libudev1:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libudev1:i386 (204-5ubuntu20.3, 204-5ubuntu20.4), libbaloofiles4:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), libsystemd-journal0:amd64 (204-5ubuntu20.3, 204-5ubuntu20.4), libnepomukcore4abi1:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), libbaloocore4:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), nepomuk-core-runtime:amd64 (4.13.2-0ubuntu0.1, 4.13.3-0ubuntu0.1), libserf-1-1:amd64 (1.3.3-1, 1.3.3-1ubuntu0.1), net-tools:amd64 (1.60-25ubuntu2, 1.60-25ubuntu2.1)
End-Date: 2014-08-16  09:03:45

I can not identify anything suspicious. Later that day I removed an older version of r-base and re-installed the latest package provided by CRAN - but that seems even more far fetched as a culprit.

Answer 1

Are you sure you didn't have any relevant package upgrades? - Because I just had two count 'em TWO kernel upgrades since friday. Maybe Lowlatency is on a different schedule but version 3.13.0-33 knocked out my wireless for a day or so (lucky for backup) and 3.13.0-34 was released, or at least was installed, on my box like the next day (Sunday) and things seem to be more stable now.

You can avoid kernel upgrades and packages that make serious changes to your system by using the commands:

sudo apt-get update
sudo apt-get upgrade

apt-get upgrade allows people who may be using Ubuntu for school or work (for production) to apply security updates and bug fixes without inadvertently screwing up some important project or deadline you may be facing.

You may sometimes notice packages listed as "held back" when you run these kinds of updates. This allows you to review these packages so you can make your own call on weather or not you want to take the chance of upgrading to a new kernel other package.

---

On the other hand, to blindly run all updates with no regard for the consequences this may have on the stability of your system, or if you're just feeling dangerous, you can run:

sudo apt-get update
sudo apt-get dist-upgrade

instead. This will install kernel upgrades and other packages that may possibly make changes to the system that could temporarily effect stability or otherwise change the way things work.

If you've used 14.04 this long and are only now experiencing a problem, I wouldn't expect too many problems in the future as most of the problems that exist are bugs that get dealt with as time goes on. Just stick to apt-get upgrade when you need to be safe and stable and maybe only do the apt-get dist-upgrade when you know it's not going to interfere with work if there happens to be a problem.