- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Apache Maintenance Basics Page 2
Security and Passwords
Keeping Apache Up to Date
Other Systems and Extensions
Checking logs is the best way to find out what is going on. Apache 2.0 introduced the generation of a separate error log for the Apache process itself. Checking this, often, is the best way to find out if something needs attention, as examining the logs makes it easy to catch a faulty or missing module or a bad process. Consider this sample fragment:
[Sat May 01 10:00:14 2004] [notice] Apache/2.0.44 (Unix) DAV/2 configured -- resuming normal operations [Sat May 01 10:00:14 2004] [info] Server built: Mar 7 2003 14:41:06 [Sat May 01 10:00:14 2004] [debug] prefork.c(1039): AcceptMutex: pthread (default: pthread) [Mon May 03 02:09:48 2004] [notice] child pid 23464 exit signal Segmentation fault (11) [Mon May 03 02:19:48 2004] [notice] child pid 10932 exit signal Segmentation fault (11) [Mon May 03 02:29:50 2004] [notice] child pid 23470 exit signal Segmentation fault (11) [Mon May 03 02:39:52 2004] [notice] child pid 23471 exit signal Segmentation fault (11) [Mon May 03 02:49:52 2004] [notice] child pid 23465 exit signal Segmentation fault (11) [Sun May 09 13:20:07 2004] [notice] child pid 21539 exit signal Bus error (10)
All log entries are marked with a particular class in much the same way as entries in the system log are marked under the various Unix variants. Log levels include 'notice', which is for notification information only; 'info', which relates to running or log information; 'debug', which is output when debugging on a module is enabled; and 'warn', which notifies of a series problem.
Checking Web host logs should also be a regular activity. These highlight problems with missing files, errors in CGI scripts, and users trying to access files and directories that no longer exist. Note, though, that some errors from a site are to be expected, even if everything tests out okay elsewhere.
The important things to look out for are unexpected items, rather than missteps you might repeatedly be making. For example, say you frequently forget to add a 'favicon' to your sites; you would then get many errors with browsers looking for a file which will never exist. But errors in a CGI or other item you would want to know about.
If you are on a Unix system, and using the standard error log format, the following command generates a unique list of errors from a log file:
$ tail -100 www-error_log | cut -d']' -f 4-99 | sed -e "s/, referer.*//g"|sort|uniq
pulls out the most recent 100.
$ cat www-error_log | cut -d']' -f 4-99 | sed -e "s/, referer.*//g"|sort|uniq
searches the entire file.
To monitor the significance, add '-c' to the uniq command, which will find you a count of the number of each error.