My Story

I have had this problem for a while now.

On my server, I run X11 whenever I work with it. Otherwise, I quit X11 since it otherwises uses a lot of resources. This gives my users a much better experience (i.e. better browsing and a lot of it happen at night for me because I live in California and I have loads of hits from France, Algeria, Tunisia, Marocco, etc.)

So... my wife and I both have a Unix account and we both start our own version of X11.

Hers rarely get stuck, mine seems to get stuck once a week or once a month.

Often, it is because after she quits I have to wait for all her X processes to quit before I start my own X11 session. X-Windows shutdown pretty quickly. However, Gnome takes its time.

So I at times have to wait a bit (I can read my emails in my console anyway)

Now, it happens that even that is not enough... that's because one of my wife's processes just does not die. And until I kill it, it simply won't work. I don't remember which process, I'll try to remember to update this page once I have the name. (generally something to do with the Nautilus and Bonobo)

But today, it was worst. I killed all the processes, then in /tmp and deleted all these many useless files (and sockets!) and it still did not want to start.

I looked for the problem for about 1h before finding it. First of all, note that you have a file called .xsession-errors in your $HOME folder. That file includes information that often give you good enough hints on the error. The fact is, I deleted many sockets but not the right ones! There were sockets in /tmp/.ICE-unix that I missed because I did not think of using -a on the ls command line when looking at the /tmp folder. Argh! Deleting all of these sockets fixed the problem.

Problem

startx starts X11 properly, but the Gnome environment does not appear. After a while you get some windows that are saved in your Gnome session, but these are border less, all in the top-left corner and totally unusable. If you do not have session windows, you may just see the background and the startup screen.

Hints

To get out of that "dead" screen one can just reset their computer. That would actually solve the whole problem. However, a better idea is to find out why this happens...

1. To get out of a "dead" X11, use Ctrl-Alt-F12
2. To stop X11, go to the console where you typed startx and hit Ctrl-C
3. To search for X11 errors, look into ~/.xsession-errors

Solutions

WARNING:

The solutions offered here are for one user computers. If you have multiple users accessing the same X11 server, be sure to look into whether other users will also be affected.

Other user process(es)

Use the ps command to see the processes. For instance, if the other person using your computer is called Elyzabeth you can type:

ps -ef | grep Elyzabeth

to list the processes that Elyzabeth is still running. Whether she is still logged in, she may still be running some processes.

Once you determined that some X11 or Gnome processes are still running, kill them:

sudo kill 123

Replace the 123 with the PID1

Repeat the kill for each X11 process.

Try starting X11 again.

Note:

esd is one of the processes that can get stuck. This is a strange one. At times it quits, at times it doesn't, at times several are running in parallel and at times it simply gets stuck and you have to kill that process also.

Your own socket from now dead processes

A process that opens a Unix socket using a filename will leave a trace behind itself when it exits if it does not erase the file first. In most cases the files do get deleted. Once in a while, they do not get deleted and thus the socket remains available although not working.

For X11, so far, all the sockets end up in /tmp or a sub-folder thereof.

There are two notorious processes leaving sockets: ICE and Nautilus.

The one that generates the problem even after all processes were killed is ICE. The folder to look at is /tmp/.ICE-unix Notice that it is a hidden folder!

To fix the problem do this (from outside of X-Windows):

rm /tmp/.ICE-unix/*

Files from other people won't get deleted (permission denied) and that's fine. (Unless they are also logged out, in which case you may want to use sudo to delete all the files. But please, check what else is in there, just in case...)

There are also sockets under:

orbit-<name>/*
/tmp/virtual-<name>.<key>/*

which you also may need to delete.

Automate the Solutions

Deep inside X11

It is possible to automate the killing of the processes and the removal of the sockets (although this one I don't have a problem with anymore...) by adding a process to run when exiting a session or run that process when starting a new session.

The content of the script would probably use the name of a process in case of the kill instruction (instead of the process identifier that cannot automatically be known at the time you quit X11.)

  su -c 'killall bonobo-activation-server' $USER

The scripts are run as root so we use su to switch to the currently logged in user (i.e. the person who runs startx). That way the killall limits its killing to that user and leaves the other users processes running.

The location and name of the scripts will vary depending on the X11 version your using. For Ubuntu 10.04 the scripts are under /etc/X11/Xsession.d for the start process and /etc/X11/Xreset.d for the shutdown. By default, the Xreset.d folder is empty. Btw, I'll have to confirm that this works...

Note that this happens to me because I use startx in my console. If you automatically boot in gdm then you never really quit X11 and thus don't have to reset those processes.

Directly in startx

At this time I just edited my startx script with the following (red lines are my additions):

  xinit "$client" $clientargs -- "$server" $display $serverargs
  
  retval=$?
  if [ x"$enable_xauth" = x1 ] ; then
    if [ x"$removelist" != x ]; then
      xauth remove $removelist
    fi
    if [ x"$xserverauthfile" != x ]; then
      rm -f "$xserverauthfile"
    fi
  fi
  
  # Added by Alexis
  sleep 3
  killall evolution-data-server-2.28

This is enough for me since I'm the only user and the startx script runs as yourself so the killall can only kill your own processes (instead of all the processes of that name.)

So far, that has worked greatly.

• 1. Process IDentifier