Section 32.6. Objective 6: Troubleshooting Environment Configurations

32.6. Objective 6: Troubleshooting Environment Configurations

In this section, we'll cover items not covered in previous sections.

32.6.1. Authorization Problems

Authorization problems are usually related to the /etc/passwd, /etc/shadow, and/or /etc/group files. Modern Linux systems offer other security systems that may be involvednotably Pluggable Authentication Modules (PAM) and SELInux, a series of patches made by the National Security Agencybut those are special cases and haven't shown up on the tests (yet!).

Generally speaking, problems related to these files are caused by hand-editing the files instead of using the system tools to modify them.

32.6.2. crontab Problems

The programs cron and at deal with scheduling jobs: cron continally reruns jobs according to schedules in the config files; at will execute a job just once at some future time.

Every user has a crontab file. They are located in /var/spool/cron on Red Hat- and Debian-based systems, On some systems, root's crontab file is considered personal to root and runs whatever root wants to schedule, while on other systems, root's crontab file is considered the system crontab file and is used to schedule system jobs.

There is also a global /etc/crontab on Red Hat systems that is used to schedule system jobs. This crontab file simply runs scripts (not other crontab files!) located in the directories /etc/cron.daily, /etc/cron.hourly, /etc/cron.weekly, and /etc/cron.monthly. The directory /etc/cron.d contains crontab files (not scripts!) that are run by cron. There is a difference between the user crontab files and the files in /etc/cron.d: the /etc/cron.d files require a user argument; otherwise, they will not work.

Most problems with cron are not cron problems but rather permission or configuration problems . Permission problems occur when the user doesn't have permission to run a program or a script, so check the permissions, especially if the user wrote the script.

The configuration problem can occur because the environment that cron runs under is not the same as the user's environment. The cron environment is rather sparse, containing SHELL (set to /bin/shsee the discussion earlier in this chapter about how that affects the login files checked), LOGNAME (which may not be changed), HOME, and MAILTO. Other variables will have to be set in the crontab file or the scripts being executed.

Finally, if the file /etc/cron.allow exists and the user is not listed in the file, the user will not be allowed to use cron. Similary, if the file /etc/cron.deny exists and the user is listed there, the user will not be allowed to use cron.

32.6.3. Init Problems

init has been called "the mother of all processes" since every process on a Linux box can be traced back to init. Few things go wrong with init. Anything that does is usually a misconfiguration in the /etc/inittab file or related to the program that init is attemtping to run.

The configuration of /etc/inittab is pretty straightforward. The lines are of the form:

 id:run-levels:action:process 

where the fields are:

id

A unique one-to-four character string

run-levels

The runlevels that the process will run in

action

The action init should take with the process (see the manpage for all of the options)

process

The actual process to run

One common problem manifests itself by the following message appearing repeatedly on the console:

 init: 'ID "SV" respawning too fast : disabled for 5 minutes' 

This means there is a problem with the process associated with ID SV. The process might be segfaulting or even not exist on the machine. If you debug the process, you'll fix the "init problem."

32.6.4. Logging Problems

Most system applications send log messages to a file via the syslog facilty, which is controlled by /etc/syslog.conf. The format of the configuration file is straightforward:

 message_types                                    log_destinations 

Types of messages are listed by facility.priority (check the manpage or the section "Objective 1: System Logging" in Chapter 30 for a complete listing), and the log destination can be a file, a named pipe, a remote machine, the terminal, specific users, or everyone logged on.

Logging errors are generally a problem with the configuration in /etc/syslog.conf or, more likely, with the program sending the messages to be logged.

When debugging syslog problems, remember that syslog may not write the log entry immediately. There may be a lag of several seconds between the time syslog writes the log, the system flushes the file to disk, and you see the changes.