Squid_ The Definitive Guide - Duane Wessels [172]
helper.c
Debugging levels are assigned such that more important messages have smaller values and less important messages have higher values. Level is for very important messages, while level 10 is for those that are relatively unimportant. Other than that, there are no strict guidelines or requirements. Developers are generally free to choose which debugging levels are appropriate.
The debug_options directive determines which messages appear in cache.log. Its syntax is:
debug_options section,level
section,level ...
The default setting is ALL,1 such that Squid prints any debugging message with level 0 or 1. If you want to make even less output appear in cache.log, you can set debug_options to ALL,0.
If you want to see additional debugging for a particular component, simply add the appropriate section and level to the end of the debug_options list. For example, this line adds level 5 debugging for the FTP server-side code:
debug_options ALL,1 9,5
As with other configuration directives, you can change debug_options, then send Squid the reconfigure signal:
% squid -k reconfigure
Note that the debug_options parameters are processed sequentially, and a later value can override an earlier one. This is of particular concern if you use the ALL keyword. Consider this example:
debug_options 9,5 20,9 4,2 ALL,1
In this case, the final value overwrites all of the preceding settings because ALL,1 sets the debugging level to 1 for all sections.
Selecting appropriate debugging sections and levels is sometimes quite difficult, especially for novice Squid users. Many of the more detailed debugging messages are meaningful only to developers and those familiar with the source code. Inexperienced Squid users are likely to find many of the debugging messages meaningless and overwhelming. Furthermore, you may have difficulty isolating the debugging for a particular request or event if Squid is relatively busy. The higher debugging levels are often more useful if you can test Squid with one request at a time.
You must also be particularly careful about running Squid with high debugging levels for a long amount of time. If Squid is busy, the cache.log file grows very quickly and may eventually consume all free space on its partition. If this happens, Squid exits with a fatal message. Another concern is that performance may degrade significantly. Due to the high number of debugging messages, Squid devotes a lot of CPU resources to formatting and printing strings. It also consumes a lot of disk bandwidth writing them all to cache.log.
Core Dumps, Assertions, and Stack Traces
If you are unlucky, Squid may experience a fatal error while running. These sorts of errors come in three flavors: assertions, bus errors, and segmentation violations.
An assertion is a sanity check in the source code. It is a tool, used by developers, to make sure that some condition is always true before proceeding. If the condition is false, the program exits and creates a core file so that the developer can analyze the situation. Here is a typical example:
int some_array[100];
void
some_func(int idx)
{
...
assert(idx < 100);
some_array[idx]++;
...
}
Here, the assertion makes sure that the value of the array index is within the bounds of the array. It would be an error to access array elements greater than (or equal to) 100. If, somehow, the value of idx isn't less than 100, the program prints a message like this when it runs:
assertion failed: filename.c:123: "idx < 100"
If this happens with Squid, you'll see an "assertion failed" message in cache.log. In addition, your operating system should create a core file, which is helpful in the post-mortem analysis. I'll explain what to do with a core file at the end of this section.
A bus error is "a fatal failure in the execution of a machine language instruction resulting from the processor detecting an anomalous condition on its bus."[1] They typically occur when the processor attempts an operation on a nonaligned memory address. You are, perhaps, more likely to see a bus error