PCs

Five tips for troubleshooting Linux desktops

The Linux desktop is generally stable and trouble-free. But when the occasional issue arises, these steps will help you identify and fix the problem.

The Linux desktop is a stable environment for the end user. But even the most stable environment will have trouble now and then. When problems arise, it's always good to know how to troubleshoot the issues. But where do you start? With so many log files and different types of desktops, what are the best ways to fix an ailing Linux desktop?

Of course, since the Linux desktop environment is currently in a state of flux (with GNOME Shell and Ubuntu Unity about to be released), it's difficult to know exactly what each user is troubleshooting. But we can approach this in such a way that you can learn how to troubleshoot one desktop by seeing how to troubleshoot another.

Note: This article is also available as a PDF download.

1: Check the logs

Linux logs a lot of information. This starts with the kernel and goes all the way up to the user-space. So even desktop malfunctions will be recorded. But what log file is the best choice to begin your troubleshooting? If your desktop still runs on X.org, the most logical launch point would be the /var/log/Xorg.0.log file. In this log file, you're going to find issues regarding X Windows, which in most instances is the underlying platform for your distribution's desktop. Even if you can't log into your desktop, you can still go to a virtual terminal (hit Ctrl-Alt-F2 to go to the second virtual terminal) and view the log files. Although this will not give you any specific information about your particular desktop environment, it will help you eliminate X Windows as a problem area.

2: Log in from the command line

One of the best ways to get a good idea, in real-time, of what is causing the problem with your desktop is to log into it from the command line. This means you have to make sure your boot process stops at runlevel 3. When your system is at runlevel 3, you will be prompted for your username and password and will have nothing more than a bash prompt upon successful authentication. From that point, you will need to use an ~/.xinitrc file, add a line like gnome-session or startkde, and issue the command startx to start up. When there are problems with the desktop, you should see error messages appear that might give you clues as to what is wrong.

3: Check to see whether it's a login issue

I have seen a user login go corrupt. This could be the shadow entry for the user or corruption in the user's configuration files. The easiest way to figure this out is to try to log on with another user. If you don't have another user, you can drop to the command line and add one with the following:

sudo useradd -d /home/testuser -m testuser
sudo passwd testuser

If you can log on with the testuser user, you know something has gone awry with your regular user.

4: Diagnose inconsistent startup

Say GNOME will start up for one user, but not another. You can work with this. You'll need to log in with the user that works and then begin the process of troubleshooting with the help of the su command. Once you have logged into the working user, open up a terminal window and change to that user with the command su USERNAME (where USERNAME is the name of the user that can't log in). Now that you have taken on the identity of that user, you can begin to troubleshoot. You can do things like disable Compiz or other effects, open Nautilus, and look for corrupt files. You might also open the gconf-editor and scan it for problems. If you suspect gconf might be the issue, you can install the Gconf Cleaner tool and have it scan for problems. (Make sure you run it as the user that can't log in.)

5: Remove user configurations

As a last ditch effort, you can log into the command line and remove the .gnome2 (for GNOME) or .kde4 (for KDE). This will get rid of all user configurations for either desktop, but it will allow you to log in. If you have special scripts or files located within those directories, you can always back the directories up and then remove them. With backup copies, you can move your scripts and files back in (one at a time) until you know you can log back in successfully.

Best problem-solvers

The Linux desktop is a solid and reliable user interface. Most often, you will never have any problems with it. But in those instances where problems happen (and happen out of nowhere, of course), it's handy to know where to begin troubleshooting.

Do you have a different method of troubleshooting the Linux desktop? How about the Windows desktop? Share your favorite diagnostic tricks with fellow TechRepublic members.

About

Jack Wallen is an award-winning writer for TechRepublic and Linux.com. He’s an avid promoter of open source and the voice of The Android Expert. For more news about Jack Wallen, visit his website getjackd.net.

13 comments
BobTatus
BobTatus

I like that you have check the logs as the number one step, this is critical and often looked over. While most important information is stored here, I have found the below extremely useful in order to get further information logged to /var/log (or where ever you like) in order to help pin point issues. http://www.rootusers.com/my-top-3-linux-commands-for-logging-problems/

kelly-wilson
kelly-wilson

At this time all linux machines can only view desktop sharing presentations, One thing to note is that each Linux distribution has a different ???recommended??? method for making changes ----------------- Linux VPN

maheshtra
maheshtra

Hi all, This may be not related to this thread but I need help on this ASAP. I am trying to connect remote desktop of machine through web browser say firefox. http://ip-of-my-host:5801/ my host has Suse11 linux I have enabled RDP of the machines. But when I do http://ip-of-my-host:5801/ I get Network error. Any pointer will be appreciated. Thanks in advance

r_widell
r_widell

This is a great idea which won't work on Debian or any of it's derivatives. Why? Because Debian decided that anything beyond runlevel 2 is useless, so rather than having to go to runlevel 5 to get into a windowed desktop environment, you get the whole kit and kaboodle at runlevel2. In case you hadn't guessed, this is one of my pet peeves wrt Debian. ron

pgit
pgit

I mv ~/.kde4 .kde4.old rather than remove the user configs. If that ain't the problem just move back and you haven't left the user with a default desktop. The default desktop, especially KDE4, can be a huge annoyance. (bouncing busy cursors, useless startups in the notification area etc)

Alpha_Dog
Alpha_Dog

Check Messages, boot, and dmsg. 90% of all issues are in there. The ones that aren't or show multiple oddities are likely driver or configuration issues.

r_widell
r_widell

Are you trying to make an RDP connection or a VNC connection? An RDP server typically listens on TCP port 3389. A VNC server typically listens on TCP port 5800+DisplayID. Making a VNC connection using HTTP with a web browser normally requires a service that downloads a java applet to the browser. This service usually listens on TCP port 5900+DisplayID and requires that the vnc-java (or tightvnc-java) package is installed in addition to vnc4server (or tightvncserver).

mordocai
mordocai

I also have this pet peeve with debian, even though debian is my favorite distribution and I use it on all my PCs. While it isn't something a new user(the type who would need these instructions, IMHO) would do, you -can- configure runlevel 3 manually to be like other distro's runlevel 3. This is what I usually do.

maheshtra
maheshtra

Hi , Well I am doing remote desktop of machine through web browser. My other machine's RDP is able to open but this machine is gving problem. all ports are open on that machine. tightvnc and vncserer both packages are installed on machine.

r_widell
r_widell

Well, all of the simple steps say it should work, so some debugging is in order. Note: I'm assuming that you're connecting to these 2 machines via a common 3rd machine to eliminate potential client-configuration artifacts. 1. Establish a telnet session to (not from) port 5801 on each machine. Compare the responses. Also establish telnet sessions to port 5901 on each machine in preparation for the next step. You should see something like this: $ telnet 5801 Trying ... Connected to Escape character is '^]'. If it never gets past the "Trying ", The firewall is blocking that port. If you get a "connection refused" message, the port is open but there is no enabled service on that port. 2. Using a VNC client (varies with the installed window manager), connect to each machine at VNC:1 (port 5901). This confirms that xinetd and the VNC server are properly configured and running. 3. If you get the appropriate identical responses from both machines to both steps, then the issue is with the Java applet that gets downloaded to the browser. You'll need to monitor network traffic to both machines using a sniffer (e.g Wireshark) to see what's different and go from there.

maheshtra
maheshtra

Yes.. My all machines are of Suse-11. I have enabled Remote administration via YAST on all machines. And both system having same /etc/xinetd.d/vnc files. Also I am able to do telnet to 5801 from both machines.

r_widell
r_widell

Now we're getting to a distro-specific point. Debian-based distros don't automatically include the java applet with the vnc server, but openSUSE does. Are they both running the same distro, release & desktop manager? If not, it's going to get way to complicated for this forum. You say one of the machines (but not which one) is running Suse Linux 11. I'm familiar with openSUSE 11.[1-3], so my comments will be based on that. Did you enable Remote Administration (VNC) via YAST on both machines? Are the /etc/xinetd.d/vnc files are identical? Can you telnet into both machines at port 5801?

Editor's Picks