cache.log contains various messages such as information about Squid's configuration, warnings about possible performance problems, and serious errors. Here is some sample cache.log output:
2003/09/29 12:09:45| Starting Squid Cache version 2.5.STABLE4 for i386- unknown-freebsd4.8... 2003/09/29 12:09:45| Process ID 18990 2003/09/29 12:09:45| With 1064 file descriptors available 2003/09/29 12:09:45| Performing DNS Tests... 2003/09/29 12:09:45| Successful DNS name lookup tests... 2003/09/29 12:09:45| DNS Socket created at 0.0.0.0, port 1154, FD 5 2003/09/29 12:09:45| Adding nameserver 188.8.131.52 from /etc/resolv.conf 2003/09/29 12:09:45| Adding nameserver 184.108.40.206 from /etc/resolv.conf 2003/09/29 12:09:45| helperOpenServers: Starting 5 'redirector.pl' processes 2003/09/29 12:09:45| Unlinkd pipe opened on FD 15 2003/09/29 12:09:45| Swap maxSize 10240 KB, estimated 787 objects 2003/09/29 12:09:45| Target number of buckets: 39 2003/09/29 12:09:45| Using 8192 Store buckets 2003/09/29 12:09:45| Max Mem size: 8192 KB 2003/09/29 12:09:45| Max Swap size: 10240 KB 2003/09/29 12:09:45| Rebuilding storage in /usr/local/squid/var/cache (CLEAN) 2003/09/29 12:09:45| Using Least Load store dir selection 2003/09/29 12:09:45| Set Current Directory to /usr/local/squid/var/cache 2003/09/29 12:09:45| Loaded Icons. 2003/09/29 12:09:45| Accepting HTTP connections at 0.0.0.0, port 3128, FD 16. 2003/09/29 12:09:45| Accepting ICP messages at 0.0.0.0, port 3130, FD 17. 2003/09/29 12:09:45| WCCP Disabled. 2003/09/29 12:09:45| Ready to serve requests.
Each cache.log entry starts with a timestamp showing when the message was generated. The very first entry in this sample reports the Squid version (2.5.STABLE4) and a string identifying the operating system for which Squid was configured (i386-unknown-freebsd4.8). The process ID (18990) follows. Many cache.log entries may look cryptic (Target number of buckets: 39). In most cases, under normal conditions, you can ignore entries you don't understand. On the other hand, you may want to look over essential configuration details such as name-server addresses or HTTP server address. This sample output ends with a statement that Squid is ready to serve requests. At this point, Squid can accept HTTP connections from clients.
Usually, the cache.log file grows slowly. However, an unusual HTTP transaction or similar event may cause Squid to emit a debugging message. If such an event happens often (e.g., a DoS attack, a new virus, or sudden disk failure), the log file may grow quickly. Rotating log files reduces the chance that you'll run out of disk space.
Major errors and abnormal conditions are likely to be reported in cache.log. I recommend archiving these logs so that it is possible to go back and find the first occurrence of an unusual event. When describing a particular Squid problem on the mailing list or a similar forum, the relevant lines from cache.log may be very useful. You may also want to increase debugging levels for some sections so that others can better understand and fix your problem.
The debug_options directive controls the level of detail for cache.log messages. The default value (ALL,1) is usually the best choice. At higher levels, the unimportant messages make it harder to find the important ones. Refer to Section 16.2 for a thorough description of the debug_options directive.
Note that debugging at the highest levels (9 or 10) may add thousands of lines for each request, quickly consuming disk space and significantly degrading Squid's performance.
You can use Squid's -X command-line option to enable full debugging for all sections. This mode is particularly useful if Squid refuses to start, and the debugging levels in squid.conf are insufficient to diagnose the problem. This is also a good way to enable full debugging of the configuration file parser, before it gets to the debug_options directive. You should never use the -X when Squid is operating properly.
You can use Squid's -k debug command-line option to enable full debugging immediately on a running Squid process. This command operates as a toggle: the first invocation turns on full debugging, and the second invocation turns it off. See Chapter 5 for a general discussion about the -k option.
As I already mentioned, full debugging generates an overwhelming amount of data. This can make Squid, and the operating system, very slow. In extreme cases, you may find your terminal session becomes unresponsive after executing the first squid -k debug command. Locking yourself out while Squid is spitting megabytes of cache.log entries per second is an unpleasant experience. I find the following trick useful to get a compact, five-second debugging snapshot with less risk:
% squid -k debug; sleep 5; squid -k debug
To have Squid send copies of cache.log messages to the system log, use the -s command-line option. Only messages with debugging levels 0 and 1 are forwarded. Level 0 messages are logged with syslog level LOG_WARNING. Level 1 messages use syslog level LOG_NOTICE. All messages use the LOCAL4 syslog facility. Here is one way to configure syslogd so that these messages are saved:
Using syslog in addition to cache.log is especially handy when you maintain several Squid boxes. You can configure each local syslog daemon to forward these messages to a central host and enjoy a unified view of all caches in one location. For example, you might use this entry in /etc/syslogd.conf:
The -d level command-line option instructs Squid to dump cache.log messages to your terminal (i.e., stderr). The level argument specifies the maximum level for messages that are dumped. Note that you'll see only messages that would appear in cache.log, subject to the debug_options setting. For example, if you have debug_options ALL,1, and run squid -d2, you won't see any level 2 debugging messages.
The -d level and -N options are most useful for debugging Squid problems or quickly testing a change to the configuration file. They allow you to start Squid easily and see the cache.log messages. This option may also be useful when Squid starts from cron or a similar facility that automatically captures a program's standard error output and reports it back to the user. For example, you may have a cron job that automatically reconfigures the running Squid process:
15 */4 * * * /usr/local/squid/sbin/squid -d1 -k reconfigure