
The client sent a revalidation (conditional) request. Thus, the cache has to validate the object. Usually seen with client issued a "no-cache", or analogous cache control command along with the request. The client request placed limits affecting the response. It may not be available in earlier Squid versions. Support for this tag has been added to Squid v5 on (commit d2a6dc). See collapsed_forwarding for more details about request collapsing. Some of the more frequently questioned messages and what they mean are outlined in the KnowledgeBase:Īt least one request in this transaction was collapsed. These are accompanied by hints for better configuration where possible, and an indication of what Squid is going to do instead of the configured action. SECURITY NOTICE messages can appear during startup and reconfigure to indicate security related problems with the configuration file setting.
Attack notices may seem rather critical, but occur at level 1 since in all cases Squid also has some workaround it can perform. Administrative workarounds (extra firewall rules etc) can assist Squid in reducing the damage to network performance. A complete solution to these usually requires fixing the client, which may not be possible. 'Attacks' signatures which can appear in normal traffic are logged as regular WARNING. This is only for problems which are unambiguous. SECURITY ALERT messages indicate security attack problems being detected. This is commonly seen when testing whether to accept a client request based on some reply detail which will only be available in the future. Some impossible condition is required to pass the security test. SECURITY ERROR messages indicate problems processing a client request with the security controls which Squid has been configured with. NOTE: Some log level 1 warning messages inherited from older Squid versions exist without any prioritization tag. These usually only display at log level 1 and higher. WARNING messages indicate problems which might be causing problems to the client, but Squid is capable of working around automatically. NOTE: Some log level 0 error messages inherited from older Squid versions exist without any prioritization tag. In which case any service actions which that component would have supplied will not happen until it is resolved and Squid reconfigured. These can also occur when starting or configuring Squid components. But has not completely aborted all traffic service. Obviously if these occur when starting or configuring a Squid component it must be resolved before you can run Squid.ĮRROR messages indicate a serious problem which has broken an individual client transaction and may have some effect on other clients indirectly. Affecting all current client traffic being supplied by that Squid instance. These levels are reserved for important and critical administrative messages.įATAL messages indicate a problem which has killed the Squid process. Debug traces are not logged at level 0 or level 1. You will usually look into this file for automated error reports, when programming Squid, testing new features, or searching for reasons of a perceived misbehavior, etc.Įrror messages come in several forms. It is a matter of personal preferences to use a separate file for the squid log data.įrom the area of automatic log file analysis, the cache.log file does not have much to offer. If you start your Squid using the -s command line option, a copy of certain messages will go into your syslog facilities. The cache.log file contains the debug and error messages that Squid generates. The initial time stamp usually contains a millisecond extension. The time stamps logged into the log files are usually UTC seconds unless stated otherwise. There are a few basic points common to all log files. Some have to be explicitly activated during compile time, others can safely be deactivated during run-time. There are several log file maintained by Squid.
The logs record not only access information, but also system configuration errors and resource consumption (e.g. The logs are a valuable source of information about Squid workloads and performance.
Can I pump the squid access.log directly into a pipe?. Can I use store.log to figure out if a response was cachable?.
Why do I get ERR_NO_CLIENTS_BIG_OBJ messages so often?. I want to use another tool to maintain the log files. What is the maximum size of access.log?.