Previous Next Table of Contents

6. Squid Log Files

The logs are a valuable source of information about Squid workloads and performance. The logs record not only access information, but also system configuration errors and resource consumption (eg, memory, disk space).

6.1 access.log

There are basically two formats for the access.log file: ``native'' and ``common.'' The Common Logfile Format is used by numerous HTTP servers. This format consists of the following seven fields:

        remotehost rfc931 authuser [date] "method URL" status bytes

The native format is different for different major versions of Squid. For Squid-1.0 it is:

        time elapsed remotehost code/status/peerstatus bytes method URL

For Squid-1.1, the information from the hierarchy.log was moved into access.log. The format is:

        time elapsed remotehost code/status bytes method URL rfc931 peerstatus/peerhost

6.2 hierarchy.log

This logfile exists for Squid-1.0 only. The format is

        [date] URL peerstatus peerhost

6.3 store.log

The store.log consists of the following fields:

    time       The time this entry was logged.  The value is the
               raw Unix time plus milliseconds.

    action     One of RELEASE, SWAPIN, or SWAPOUT.
               RELEASE means the object has been removed from the cache.
               SWAPOUT means the object has been saved to disk.
               SWAPIN  means the object existed on disk and has been
                       swapped into memory.

    status     The HTTP reply code.

    The following three fields are timestamps parsed from the HTTP
    reply headers.  All are expressed in Unix time.  A missing header
    is represented with -2 and an unparsable header is represented as -1.

    datehdr    The value of the HTTP Date: reply header.

    lastmod    The value of the HTTP Last-Modified: reply header.

    expires    The value of the HTTP Expires: reply header.

    type       The HTTP Content-Type reply header.

    expect-len The value of the HTTP Content-Length reply header.
               Zero if Content-Length was missing.

    real-len   The number of bytes of content actually read.  If the
               expect-len is non-zero, and not equal to the real-len,
               the object will be released from the cache.

    method     HTTP request method

    key        The cache key.  Often this is simply the URL.  Cache objects
               which never become public will have cache keys that include
               a unique integer sequence number, the request method, and
               then the URL.

6.4 Field Definitions

These are the definitions for the various log format components:

remotehost

The IP address of the client host. In Squid-1.1, if the log_fqdn option is enabled, full hostnames will be logged when available.

rfc931

The username associated with the client connection, determined from an Ident (RFC 931) server running on the client host. By default Ident lookups are not made, but may be enabled with the ident_lookup option.

authuser

Always NULL ("-") for Squid logs.

method

GET, HEAD, POST, etc. for HTTP requests. ICP_QUERY for ICP requests.

URL

The requested URL.

code

The ``cache result'' of the request. This describes if the request was a cache hit or miss, and if the object was refreshed. See the full list of cache result codes.

status

HTTP status code: 200 for succesful actions, 000 for UDP requests, 403 for redirects, 500 for server errors, etc. See the HTTP status codes for a complete list.

bytes

The number of bytes delivered to the client.

peerstatus

A status code that explains how the request was forwarded, either too your peer (neighbor) caches, or directly to the origin server.

peerhost

The host where the request was forwarded to.

time

Unix timestamp (since Jan 1, 1970) with millisecond resolution.

date

HTTP date format: dd/mmm/yyyy:hh:mm:ss TZ-offset

elapsed

The time elapsed (milliseconds) during the client connection. For HTTP requests, this is the time between the accept() and close() system calls for the TCP socket. For ICP requests, this represents the time between scheduling the reply message for sending and actually sending it.

6.5 Cache Result Codes

Note, TCP_ refers to requests on the HTTP port (3128).

TCP_HIT

A valid copy of the requested object was in the cache.

TCP_MISS

The requested object was not in the cache.

TCP_REFRESH_HIT

] The object was in the cache, but STALE. An If-Modified-Since request was made and a "304 Not Modified" reply was received.

TCP_REF_FAIL_HIT

The object was in the cache, but STALE. The request to validate the object failed, so the old (stale) object was returned.

TCP_REFRESH_MISS

The object was in the cache, but STALE. An If-Modified-Since request was made and the reply contained new content.

TCP_CLIENT_REFRESH

The client issued a request with the "no-cache" pragma.

TCP_IMS_HIT

The client issued an If-Modified-Since request and the object was in the cache and still fresh.

TCP_IMS_MISS

The client issued an If-Modified-Since request for a stale object.

TCP_SWAPFAIL

The object was believed to be in the cache, but could not be accessed.

TCP_DENIED

Access was denied for this request

"UDP_" refers to requests on the ICP port (3130)

        UDP_HIT         A valid copy of the requested object was in the cache.
        UDP_HIT_OBJ     Same as UDP_HIT, but the object data was small enough
                        to be sent in the UDP reply packet.  Saves the
                        following TCP request.
        UDP_MISS        The requested object was not in the cache.
        UDP_DENIED      Access was denied for this request.
        UDP_INVALID     An invalid request was received.
        UDP_RELOADING   The ICP request was "refused" because the cache is
                        busy reloading its metadata.

"ERR_" refers to various types of errors for HTTP requests.

6.6 Peer Status Coces

Hierarchy Data Tags

        DIRECT                  The object has been requested from the origin
                                server.
        FIREWALL_IP_DIRECT      The object has been requested from the origin
                                server because the origin host IP address is
                                inside your firewall.
        FIRST_PARENT_MISS       The object has been requested from the
                                parent cache with the fastest weighted round
                                trip time.
        FIRST_UP_PARENT         The object has been requested from the first
                                available parent in your list.
        LOCAL_IP_DIRECT         The object has been requested from the origin
                                server because the origin host IP address 
                                matched your 'local_ip' list.
        SIBLING_HIT             The object was requested from a sibling cache
                                which replied with a UDP_HIT.
        NO_DIRECT_FAIL          The object could not be requested because
                                of firewall restrictions and no parent caches
                                were available.
        NO_PARENT_DIRECT        The object was requested from the origin server
                                because no parent caches exist for the URL.
        PARENT_HIT              The object was requested from a parent cache
                                which replied with a UDP_HIT.
        SINGLE_PARENT           The object was requested from the only
                                parent cache appropriate for this URL.
        SOURCE_FASTEST          The object was requested from the origin server
                                because the 'source_ping' reply arrived first.
        PARENT_UDP_HIT_OBJ      The object was received in a UDP_HIT_OBJ reply
                                from a parent cache.
        SIBLING_UDP_HIT_OBJ     The object was received in a UDP_HIT_OBJ reply
                                from a sibling cache.
        PASSTHROUGH_PARENT      The neighbor or proxy defined in the config
                                option 'passthrough_proxy' was used.
        SSL_PARENT_MISS         The neighbor or proxy defined in the config
                                option 'ssl_proxy' was used.
        DEFAULT_PARENT          No ICP queries were sent to any parent
                                caches.  This parent was chosen because
                                it was marked as 'default' in the config
                                file.
        ROUNDROBIN_PARENT       No ICP queries were received from any parent
                                caches.  This parent was chosen because
                                it was marked as 'default' in the config 
                                file and it had the lowest round-robin use
                                count.
        CLOSEST_PARENT_MISS     This parent was selected because it
                                included the lowest RTT measurement to
                                the origin server.  This only appears
                                with 'query_icmp on' set in the config
                                file.
        CLOSEST_DIRECT          The object was fetched directly from the
                                origin server because this cache measured
                                a lower RTT than any of the parent caches.

Almost any of these may be preceeded by 'TIMEOUT_' if the two-second (default) timeout occurs waiting for all ICP replies to arrive from neighbors.

6.7 HTTP status codes

These are taken from RFC 2068.

100  Continue
101  Switching Protocols
200  OK
201  Created
202  Accepted
203  Non-Authoritative Information
204  No Content
205  Reset Content
206  Partial Content
300  Multiple Choices
301  Moved Permanently
302  Moved Temporarily
303  See Other
304  Not Modified
305  Use Proxy
400  Bad Request
401  Unauthorized
402  Payment Required
403  Forbidden
404  Not Found
405  Method Not Allowed
406  Not Acceptable
407  Proxy Authentication Required
408  Request Time-out
409  Conflict
410  Gone
411  Length Required
412  Precondition Failed
413  Request Entity Too Large
414  Request-URI Too Large
415  Unsupported Media Type
500  Internal Server Error
501  Not Implemented
502  Bad Gateway
503  Service Unavailable
504  Gateway Time-out
505  HTTP Version not supported

6.8 cache/log

This file has a rather unfortuntate name. It also is often called the swap log. It is a record of every cache object written to disk. It is read when Squid starts up to ``reload'' the cache. If you remove this file, you will effectively wipe out your cache contents.

For Squid-1.1, there are six fields:

  1. fileno: The swap file number holding the object data. This is mapped to a pathname on your filesystem.
  2. timestamp: This is the time when the object was last verified to be current. The time is a hexadecimal representation of Unix time.
  3. expires: This is the value of the Expires header in the HTTP reply. If an Expires header was not present, this will be -2 or fffffffe. If the Expires header was present, but invalid (unparsable), this will be -1 or ffffffff.
  4. lastmod: Value of the HTTP reply Last-Modified header. If missing it will be -2, if invalid it will be -1.
  5. size: Size of the object, including headers.
  6. url: The URL naming this object.

6.9 Which log files can I delete safely?

The best way to maintain Squid log files is to send the squid process a USR1 signal. This causes the current log files to be closed and renamed. You can then remove any of the old log files. For example, if your squid.pid file is /usr/local/squid/logs/squid.pid/ (as defined in your squid.conf file) you would do:

        kill -USR1 `cat /usr/local/squid/logs/squid.pid`

NOTE: The logfile_rotate line in squid.conf makes it generally unnecessary to delete logfiles by hand. Just set logfile_rotate to the number of old logs you want saved. Each time the value of logfile_rotate is reached, the oldest log will be deleted automatically. You may find it useful to simply set logfile_rotate to the number of old logs you want, and then set up a crontab to send squid the SIGUSR1 signal. The following crontab entry would tell Squid to rotate the logs every day at midnight:

        0 0 * * * /bin/kill -USR1 `cat /usr/local/squid/logs/squid.pid`

The only logfile you should never delete is the file cleverly named log which normally exists in the first cache_dir directory. This file contains the meta data needed to rebuild the cache when squid starts up. Deleting this file effectively wipes out your cache.

6.10 Why do I get ERR_NO_CLIENTS_BIG_OBJ messages so often?

This message means that the requested object was in ``Delete Behind'' mode and the user aborted the transfer. An object will go into ``Delete Behind'' mode if

6.11 What does ERR_LIFETIME_EXP mean?

This means that a timeout occurred while the object was being transferred. Most likely the retrieval of this object was very slow (or it stalled before finishing) and the user aborted the request. However, depending on your settings for quick_abort, Squid may have continued to try retrieving the object. Squid imposes a maximum amount of time on all open sockets, so after some amount of time the stalled request was aborted and logged win an ERR_LIFETIME_EXP message.

6.12 Retrieving ``lost'' files from the cache

I've been asked to retrieve an object which was accidentally destroyed at the source for recovery. So, how do I figure out where the things are so I can copy them out and strip off the headers?

The following method applies only to the Squid-1.1 versions:

Use grep to find the named object (Url) in the cache/log file. The first filed in this file is an integer file number.

Then, find the file fileno-to-pathname.pl from the ``scripts'' directory of the Squid source distribution. The usage is

        perl fileno-to-pathname.pl [-c squid.conf]
file numbers are read on stdin, and pathnames are printed on stdout.


Previous Next Table of Contents