Reordering or changing system services during a particular runlevel is rarely necessary when using Ubuntu unless some disaster occurs. But system administrators should have a basic understanding of how Linux boots and how services are controlled in order to perform troubleshooting or to diagnose problems. By using additional utilities such as the dmesg | less command to read kernel output after booting or by examining system logging with cat /var/iog/messages | less, it is possible to gain a bit more detail about what is going on when faced with troublesome drivers or service failure.
To better understand how to troubleshoot service problems in Ubuntu, look at the diagnosis and resolution of a typical service-related issue.
In this example, x will not start: You don't see a desktop displayed, nor does the computer seem to respond to keyboard input. The x server might either be hung in a loop, repeatedly failing, or might exit to a shell prompt with or without an error message.
The x server only attempts to restart itself in runlevel 5, so to determine whether the x server is hung in a loop, try switching to runlevel 3.
If you are working on a multi-user system and might inadvertently interrupt the work of other users, ask them to save their current work; then change to a safer runlevel, such as single user mode.
Change to runlevel 3 by switching to another virtual console with Ctrl+Alt+F2, logging in as root, and running the command telinit 3. This switch to runlevel 3 will stop the x server from attempting to restart itself.
Now you can easily examine the error and attempt to fix it.
First, try to start the x server "naked" (without also launching the window manager). If you are successful, you will get a gray screen with a large x in the middle. If so, kill x with the Ctrl+Alt+Backspace key combination, and look at your window manager configuration. (This configuration varies according to which window manager you have chosen.)
Let us assume that x won't run "naked." If we look at the log file for Xorg (it's clearly identified in the /var/log directory), we'll pay attention to any line that begins with (ee) , the special error code. We can also examine the error log file, .xsessions-error, in our home directory if such a file exists.
If we find an error line, the cause of the error might or might not be apparent to us. The nice thing about the Linux community is that it is very unlikely that you are the first person to experience that error. Enter the error message (or better, a unique part of it) into http://www.google.com/linux and discover what others have had to say about the problem. You might need to adjust your search to yield usable results, but that level of detail is beyond the scope of this chapter. Make adjustments and retest as before until you achieve success.
Fix the x configuration and start x with startx. Repeat as necessary.
Before making any changes to any configuration file, always make a backup copy of the original, unmodified file. Our practice is to append the extension .original to the copy because that is a unique and unambiguous identifier.
If you need to restore the original configuration file, do not rename it, but copy it back to its original name.
Was this article helpful?