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.
Starting and Stopping Services Manually
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.d name on the command line with an appropriate keyword, such as start, status, or stop. For example, to start the automated nightly update of the yum RPM package database, call the /etc/rc.d/init.d/yum script 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 status keyword 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 yum example looks like this:
# service yum start
Nightly yum update is enabled: [ OK ]
Of course, the GUI tools mentioned earlier also have the functionality to start and stop specific services in your current runlevel. The tool you choose is a matter of personal preference; a good system administrator is aware of them all.
Here are some of the commands you learned so far:
> chkconfig — Fedora's text-only command-line runlevel configuration utility
> ntsysv — Fedora's text-based system services configuration tool for the command line
> setup — Actually a bash script, it is a menu to all the individual ncurses-based configuration tools, including ntsysv
> system-config-services — Fedora's GUI runlevel configuration tool, named Configure Services
> telinit — Changes the current runlevel
Scheduling Tasks
There are three ways to schedule commands in Fedora, all of which work in different ways. The first is the at command, which specifies a command to run at a specific time and date relative to today. The second is the batch command, which is actually a script that redirects you to the at command with some extra options set so that your command runs when the system is quiet. The last option is the cron daemon, which is the Linux way of executing tasks at a given time.
Using at and batch to Schedule Tasks for Later
If there is a time-intensive task you want to run, but you do not want to do it while you are still logged in, you can tell Fedora to run it later with the at command. To use at, you need to tell it the time at which you want to run and then press Enter. You then see a new prompt that starts with at>, and everything you type there — until you press Ctrl+D — comprises the commands you want at to run.
When the designated time arrives, at performs each action individually and in order, which means later commands can rely on the results of earlier commands. In this next example, run at just after 5 p.m., at is used to download and extract the latest Linux kernel at a time when the network should be quiet:
[paul@caitlin ~]$ at now + 7 hours
at> wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.10.tar.bz2
at> tar xvfjp linux-2.6.10.tar.bz2
at> <EOT>
job 2 at 2005-01-09 17:01
Specifying now + 7 hours as the time does what you would expect: at was run at 5 p.m., so the command runs just after midnight that night. When your job finishes, at sends you mail with a full log of your job's output; type mail at the console to bring up your mailbox and then press the relevant number to read at's mail.
If you have a more complex job, you can use the -f parameter to have at read its commands from a file, like this:
