Linux Lab Session Problems
If, when you log in to a linux lab machine, you get a black desktop with no icons or menus, or a desktop with menu bars but no actual menus, or something similar to that — an environment in which you can't do anything, essentially — here are some steps you can take to try to correct the problem.
First, you'll want to log out. If you're working directly at a lab machine, you can do this by typing control-alt-backspace. NOTE: That's backspace, not delete. Control-alt-delete will reboot the whole computer, which could cause problems for other people using that machine remotely.
If you're using tsvnc, you'll need to log in again using a command-line client and kill your stuck connection. To do that, follow the instructions for getting to a command line on the same machine you connected to graphically. Once you have a command line on that machine, type this command:
killall -u your_netid
Replace “your_netid” with your actual netid, the one you use to log in. This should kill all processes running as you on that machine, including the shell you just used to kill everything.
Once you've stopped your frozen graphical session, you'll need to log in to a command line and remove some files. If you're connecting remotely, just follow the same steps you did previously to get a shell. If you're in the lab, you can get a non-graphical login prompt by pressing control-alt-F2.
Once you have a shell prompt, run these commands:
cd ~ rm -fr .gnome* .gconf* .nautilus
Once you've run those commands, log out (using the
exit command). If you're in the lab, press control-alt-f7 to return to the graphical login screen.
You should now be able to log in to a graphical session.
I don't know why this is happening, but removing those directories seems to help. I've seen the problem happen a few different ways, requiring different subsets of those files to be removed before it's resolved, so removing all of them should do the trick. You lose a few preferences in the process, but I figure that's better than not being able to log in.
My current thinking is that it might be related to the different versions of RHEL in the labs. It seems to be pretty safe to log in to multiple machines of exactly the same type and version simultaneously, but I'm not sure what happens if, say, you're logged into a 32-bit RHEL5 and a 64-bit RHEL6 system at the same time. Further investigation is required.