Troubleshooting Runlevel Problems
Troubleshooting Runlevel Problems
Reordering or changing system services during a particular runlevel is rarely necessary when using Fedora unless some disaster occurs. But system administrators should have a basic understanding of how Linux boots and how services are controlled 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/log/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 Fedora, look at the diagnosis and resolution of a typical service-related issue. In this example, X doesn't start: You don't see a desktop displayed, nor does the computer seem to respond to keyboard input. The X server might be hung in a loop, repeatedly failing, or might exit to a shell prompt with or without an error message.
The X server attempts to restart itself only 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 multiuser 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 stops the X server from attempting to restart. 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 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's assume that X won't run "naked." If you look at the log file for Xorg (it's clearly identified in the
/var/log directory), pay attention to any line that begins with (EE), the special error code. You can also examine the error log file,
.xsessions-error, in the home directory if such a file exists.
If you find an error line, the cause of the error might or might not be apparent. One 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.
- Avoiding Printer Support Problems
- Troubleshooting DNS
- Delegation Problems
- Troubleshooting Build Issues
- Appendix B. Common problems and questions
- Problems loading modules
- mIRC DCC problems
- System Services and Runlevels
- Runlevel Definitions
- Booting into the Default Runlevel
- Booting to a Nondefault Runlevel with GRUB
- Changing Runlevels