Chapter 18 Troubleshooting Software and Networking

539

These logs will give you specific error messages, and help you narrow down the problem fairly quickly.

Other failures can be caused by misconfiguration of your backup scheme. If you have your software set to put all of your backups on one tape, you increase the possibility that the tape will become full before the operation is complete — causing the backup to fail.

Retention settings may also be misconfigured. Retention is a setting that lets the application know how long data on a tape should be retained before it is written over. If you try to backup to a tape that is still retaining data, the system won’t overwrite the data, and therefore, cause the backup to fail.

Another cause of backup failures is open files. If you’re trying to back up your Linux server during working hours, your users may have many open files, which won’t be backed up. Schedule your backups for off-hours when those files will be closed.

If you aren’t using a special backup application, you may be simply dumping file systems to tape, scheduled by the cron daemon. Examine your cron logs to make sure that the system is being backed up properly. If cron is not running or not executing the schedule, your system is not being backed up.

File restore errors

When restoring files from tape, you may run into problems other than mechanical or media problems.

For example, the backup application must have the proper permissions to restore a file to a particular directory. You must also be careful about restoring a file with the same name as the original. Restore the file to a different directory than the original file so it won’t be overwritten. This way, the user can compare the files if they need to copy any changes or retain information entered in the new file.

When restoring large files and directories, take note of how much disk space the restored files will consume. If you don’t have enough disk space, the restore operation will fail, and as a result, may cause other problems to occur on the server.

Application Failures

6.13 Identify application failure on server (e.g., Web page, telnet, ftp, pop3, snmp)

On a stable Linux system, you will rarely encounter a problem on the operating system. This process reliability is different for actual application programs and process daemons, which can cause problems due to misconfiguration, errors from bad input, and general process failure. Most of the time, the users will see the symptoms

540	Part VI Troubleshooting and Maintaining System Hardware

of the problem before the administrator because they are the ones constantly using the applications throughout the day. These problems can range from simple, noncritical services to critical application processes and programs, such as mail, Web, and file-sharing services.

You can discover and remedy application and process errors in a number of ways by using the process logs and startup script tools of the Linux system.

Know how to properly test and troubleshoot systems for various application errors, including Web, FTP, and telnet.

Log files

When you first discover an application failure, check the log file for that application, or check the main system log file if the application is a system process.

By examining the error messages, you may be able to quickly ascertain the exact problem. The problem may have been a misconfiguration error that occurred after changes were made to an application configuration file, or the problem may have occurred for other general reasons, such as low disk space or system resources.

Most application and process log files are stored in the /var/log directory. The main system log file is located in /var/log/messages. In this log file, you will find the informational and error messages from any system processes or applications, including kernel system messages.

You can find other more application-specific log files in the /var/log directory as well. Some applications, however, store their log information in the same directory where the application is located.

Process and daemon errors

You and your users will notice most process errors when a certain service won’t perform its function. Process errors can range from the non-critical services, such as cron or snmp, to system-critical functions, such as a live Web server, logins, or file sharing.

You can examine most of these problems through the system and application log files. Most process errors stop due to an error, or have lapsed into a frozen state because of some system error.

You can stop, start, or restart services by using their respective scripts in the /etc/rc.d/init.d directories. For example, to stop, start, or restart the cron daemon, use the following commands:

crond stop crond start crond restart

Chapter 18 Troubleshooting Software and Networking

541

Web server errors

If your Web server is not serving pages, check for the existence of the Web server daemon, httpd, by using the following command:

ps -ef | grep httpd

If your Web server is running but not working, or if the process does not seem to be running, then it is either in a frozen state or stopped.

You can stop, start, and restart the service using the script in /etc/rc.d/init.d/ httpd. For example, if the process is not running, use the following command:

httpd start

If the Web server is running but not working properly, use the following commands:

httpd stop httpd start

Check to see if the Web server is running by first checking the process with ps, then try connecting to a Web page.

Telnet

You can easily check telnet services for a host by attempting to connect from the same machine to its local port. For example, to test that your telnet daemon is properly listening for connections, use the following command:

telnet localhost

If the telnet command does not respond with a login prompt, then your telnet service may be turned off or the network services daemon inetd is not running.

Examine the /etc/inetd.conf file for the telnet section. Many people turn off the telnet services as a security measure. You can disable the telnet service by commenting the appropriate line out from inetd.conf. If you want to re-enable the service, uncomment it from the file, and restart the inetd daemon.

FTP

FTP services are also run from the inetd daemon, which is similar to the telnet service. Examine the /etc/inetd.conf file to see if ftp services are disabled, and enable them if necessary.