Re: Cache index mangled?

From: Stewart Forster <>
Date: Mon, 10 Nov 1997 10:10:36 +1100

> It happens with 1.1.17 too. I set it up only one week ago, shut it down recently
> and relaunched it. I have the very same problem: some sites are redirected to
> another (the home page of our school). What I don't understand is how this page
> came into the cache because I put our domain name in the cache_stoplist!
> Please send it.


        if(store_rebuilding == STORE_REBUILDING_SLOW)
            return -1;

into the storeSwapInStart function in store.c. Put the code right at the
very start of the function (of course just after the local variable declar's).

What will it do:

        While your store is rebuilding at any time, this code effectively
causes all attempts to read in a on-disk file to fail.


        Because squid as of about 1.1.10 (from memory) uses re-usable swap
file numbers, there exists a race condition that is caused by the following
sequence of events:

        Consider a normally running squid daemon-

        URL1 comes in - gets assign to swapfileno X - squid writes this
            to the `log' file as "swapfilenoX blah URL1"
        URL1 gets ejected after some time - swapfileno X get added to stack
        URL2 comes in - X is first on the free swapfileno stack - X gets
           assigned to Object 2, squid writes object 2 over the top of the
           old swap file corresponding to X. Squid writes to log file
           "swapfilenoX blah URL2"

        Now squid dies unnaturally - cannot write out clean swap log file

        Squid restarts and starts reading in the "log" file.
        Finds "swapfilenoX blah URL1", now URL1 points at the swapfilenoX that
            really is now owned by URL2
        Request comes in for URL1. Squid serves up URL2 instead, which almost
            always in porn.

        This situation is also going to happen more frequently to frequently
accessed URLs, thing like home pages, netscape, microsoft, geocities, etc, so
eveyone notices when it does happen. :(


        Whiel squid is doing a slow reload, it almost goes purely into a
proxy-only mode, and will not serve up any on-disk objects. It will however
continue to serve up in-memory hot-cache objects that have been loaded in
since the restart (these are known to be "clean"), so not all possible hits
are lost.

Other caveats:

        I have noticed that even the above code MAY fail. In that case, we
moved to the more extreme:

        if(store_rebuilding != STORE_NOT_REBUILDING)
            return -1;

but this prevents disk served objects even when the "log" file is supposedly
clean, but this option is worth a try.

> Is there a way to solve the problem by hand not doing a squid -z?

        No. Once the cache is corrupted it's done for. If you want to risk
a small amount of corruption you can apply the above patch and restart
squid. Then shift-reload up all the known corrupted pages. This will force
out all the old URL-swapfileno mappings that may have been corrupt. This
method of course only works for those URLs you know to be corrupt, which MAY
be enough for you.



Stewart Forster (Traffic and Web Proxy Cache Administrator) pty ltd, Level 9, 114 Albert Rd, Sth Melbourne, VIC 3205, Aust.
Email:   Phone: +61 3 9251-3684   Fax: +61 3 9251-3666
Received on Sun Nov 09 1997 - 15:14:14 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:37:28 MST