Andrew Hudson - Fedora™ Unleashed, 2008 edition

Here is a sample listing of the rsyncfile /etc/xinet.d/rsync:

# default: off

# description: The rsync server is a good addition to an ftp server, as it \

# allows crc checksumming etc.

service rsync {

disable = yes

socket_type = stream

wait = no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

}

The items are straightforward and vary from service to service. Although you can edit this by hand, it can be configured via the command line or graphical service configuration clients.

After making changes to system services and runlevels, you can use the telinitcommand to change runlevels on the fly on a running Fedora system. Changing runlevels this way enables system administrators to alter selected parts of a running system to make changes to the services or to put changes into effect that have already been made (such as reassignment of network addresses for a networking interface).

For example, a system administrator can quickly change the system to maintenance or single-user mode by using the telinitcommand with its S option, like this:

# telinit S

The telinitcommand uses the initcommand to change runlevels and shut down currently running services. The command then starts services for the specified runlevel; in this example, the single-user runlevel is the same as runlevel 2. The initcommand can be run only from a console, not from an xtermrunning in an X session.

After booting to single-user mode, you can then return to multiuser mode without X, like this:

# telinit 3

If you have made changes to the system initialization table itself, /etc/inittab, use the telinitcommand's q command-line option to force initto re-examine the table.

Linux is full of shortcuts: If you exit the single-user shell by typing exitat the prompt, you go back to the default runlevel without worrying about using telinit.

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/logdirectory), 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.

If you change a configuration file for a system service, it is usually necessary to stop and restart the service to make it read the new configuration. If you are reconfiguring the X server, it is often convenient to change from runlevel 5 to runlevel 3 to make testing easier and then switch back to runlevel 5 to re-enable the graphical login. If a service is improperly configured, it is easier to stop and restart it until you have it configured correctly than it is to reboot the entire machine.

There are several ways to manually start or stop services or to change runlevels while using Fedora. The traditional way to manage a service (as root) is to call the service's /etc/rc.d/init.dname on the command line with an appropriate keyword, such as start, status, or stop. For example, to start the automated nightly update of the yumRPM package database, call the /etc/rc.d/init.d/yumscript like this:

# /etc/rc.d/init.d/yum start

Enabling nightly yum update: [ OK ]

The script executes the proper programs and reports their status. Stopping services is equally easy, and in fact, you can also check the status of some services by using the statuskeyword like this:

# /etc/rc.d/init.d/yum status

Nightly yum update is enabled.

In this example, the yum script reports that the daemon is running. This information might be useful for other system management tasks.

A much easier way to manually start or stop a service is to use a script named service.Using service, you do not have to know the full pathname to the system service; you need know only the name of the system service you want to manipulate. Using this approach, the previous yumexample looks like this:

# service yum start