ntsysv command.
Fedora's developers have added GUIs to many text-only, command-line-based system administration tools as Linux has matured. These tools provide an easier-to-use interface and don't require memorization or lookup of command-line options. Fedora provides its own Service Configuration tool for the control and administration of services (see Figure 11.3). You can access the GUI menu selection from the System Settings/Server Settings menu, and then select Services. The command-line name of this tool is system-config-services.
FIGURE 11.3 The new Service Configuration tool enables you to select runlevels to edit, displays all the available services, and provides an explanation of what the service does.
Running Services Through xinetd
The xinetd daemon is a replacement for inetd; it listens for requests for services on certain ports and starts those services as required. xinetd is called a super server because it controls other servers. Its purpose is to conserve resources by not running services when not needed. The xinetd daemon is more secure than the older inetd, offers better logging facilities than inetd, and can redirect service requests to another machine. It does not require the root user to start any services.
The configuration file for xinetd is found at /etc/xinetd.conf; configuration files for individual services are located in /etc/xinet.d/; the particulars of its format are covered in the man page for xinetd.conf, which also provides a sample file listing. Fedora provides the appropriate server RPM packages already configured to use xinetd if possible. If you are installing servers manually from source code, the included documentation describes the appropriate xinetd configuration. Services run under xinetd cannot be started and stopped in the same manner as the services run from scripts in /etc/rc.d/init.d; you must restart the xinetd service itself and let it control those services.
Here is a sample listing of the rsync file /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.
Changing Runlevels
After making changes to system services and runlevels, you can use the telinit command 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 telinit command with its S option, like this:
# telinit S
The telinit command uses the init command 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 init command can be run only from a console, not from an xterm running 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 telinit command's q command-line option to force init to re-examine the table.
Linux is full of shortcuts: If you exit the single-user shell by typing exit at the prompt, you go back to the default runlevel without worrying about using telinit.
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
