Auto login XFCE without a display manager

I have a low-spec and now somewhat obsolete notebook, on which I run Debian and XFCE. The machine boots in under ten seconds, which is really convenient – but I would like it to boot even faster!

After initial install, I used to use GDM to auto-login to the XFCE session. However I noticed that starting GDM was slow – there was a noticeable pause around this time during bootup, which didn’t occur when starting X from the command line using startx, xinit, startxfce4, etc.
I imagine that things would get even worse with GDM3 and all of its heavy dependencies – but I haven’t even tried it, as I intensely dislike GNOME 3‘s developers’ attitudes, its lack of configurability and bloat as compared to XFCE.

First I switched from GDM to XDM, which was a slight improvement, but starting XDM still took a perceptible time, and I was intent on trimming every microsecond off the bootup time.

All I need is something to start my local X session and auto login Xfce, which startx etc does just fine. Given this, for me a display manager was a pointless waste of CPU, memory and disk.

So I resolved to auto-login my user from inittab, then auto-start an X session from the user’s shell login scripts.

Auto-logging in a user

This part is relatively easy – we just edit /etc/inittab, and modify the entry for tty7 (which on many *NIXen, including Linux, is reserved for X Windows) in runlevel 5 (on Linux, usually reserved for normal startup with X) so it continuously auto-logs-in the user.

I used mingetty for this purpose, but agetty and some other getty variants should also work.

7:5:respawn:/sbin/mingetty --autologin myuser --noclear tty7

Careful: Incorrect edits to inittab are a good way to cause your system to fail to boot. Google is your friend.

Note: Using a getty variant that supports auto-login is superior to running login -f, as for example suggested in this Debian User Forums thread.

While I was twiddling inittab I disabled all but one of the other text console gettys, to save a small amount of RAM and CPU. I hardly ever use the text consoles anyway – pretty much only when X craps out.

On this Debian system, I needed to install additional packages to ensure that logging into a text console gave me a valid ConsoleKit session:

sudo apt-get install consolekit libpam-ck-connector

Now to test things so far:

  1. From a shell, tell init to re-examine the modified /etc/inittab:
    sudo telinit Q
  2. Log out of all ttys and X sessions, to avoid potentially-confusing additional output in the following steps.
  3. Switch to tty7 using alt+F7. Check that you see an already-logged-in shell, with the usual shell prompt.
  4. Check that the ConsoleKit session is valid:
    You should only see one session – if you see more than one, you might still be logged in on another tty, or there may still be an X session running somewhere.
    Examine the output of ck-list-sessions, and confirm the presence of the following two lines:
    active = TRUE
    is-local = TRUE

    If these aren’t present, ConsoleKit and/or PAM aren’t set up correctly. One possible problem is absence of the package libpam-ck-connector.

Auto-starting XFCE

This causes an X session to be started whenever the user logs in on tty7 (but not on any other tty) and no X session is already running.

Removing the check for tty7 would cause an X session to be started upon every console login shell, which is probably not what you want.

  1. Edit ~/.bash_profile and add to the end of the file:
    if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty7 ] ; then
        startx -- -novtswitch -nolisten tcp -br vt7

    Save the file and exit.
  2. Log out of tty7. The login should be auto-restarted due to the steps above, and the change just made should cause an X session to be started on tty7.
  3. Tweak your X session as desired.

Fixing ConsoleKit

At this point I noticed a problem with this set-up which had not occurred when using GDM: when I chose “Log Out” from the XFCE menu, I could only log out – the options to restart, shut down etc, which had previously been available, were now present but greyed out. This is a common problem, usually caused by one of a variety of ConsoleKit and/or DBus problems.

After some Googling and experimentation, I discovered that this was because in addition to the correct ConsoleKit session being started upon text console login, an incorrect one was being started by the X session startup scripts.

The culprit is /etc/X11/Xsession.d/90consolekit – as of time of writing, it assumed that if not using GDM (which automatically creates a CK session) and if on the console (not already in X), another CK session should be started.

This is not correct; we already have a perfectly good CK session, so don’t need another one, and anyway the one started by this script is b0rken such that the logged-in user is not ‘is-local’, so lacks the permission to send the DBus messages that are required to shut down/restart the machine from the XFCE logout dialog.

The fix is simple – prevent this script from starting the additional broken ConsoleKit session:

  1. Edit the offending script:
    sudo nano /etc/X11/Xsession.d/90consolekit
  2. Towards the end of the file, comment out the lines reading:
    if [ -z "$GDMSESSION" ] && [ -x "$CK_LAUNCH_SESSION" ] && \
     ( [ -z "$XDG_SESSION_COOKIE" ] || is_on_console ) ; then

    Note: To fix the problem, the minimal change is to comment out the line modifying variable STARTUP. However, commenting out all of these lines as suggested above also avoids significant unnecessary work during X startup. As mentioned by a comment in the same file just above these lines, the DBus calls made by shell function is_on_console (at start of this file) are expensive.
  3. Log out of the X session, whereupon you should be back at the text-console shell on tty7.
  4. Log out of the shell on tty7, whereupon init should restart it, which should restart the X session too.
  5. Check that the shut down, restart etc options are now available (no longer greyed out) in the Xfce logout options dialog.

Leave a Reply

Your email address will not be published. Required fields are marked *