Re: [squid-users] what should squid -z do

On 4/02/2013 7:54 a.m., Eliezer Croitoru wrote:
> On 2/3/2013 8:29 PM, Alex Rousskov wrote:
>> The cause of this specific problem is_not_ rock behavior (correct or
>> not) but a mismatch between a startup script and squid.conf -- the
>> script does not test for all the right directories when running squid-z.
>> Even if rock code is changed, this mismatch still needs to be fixed.
>> Please consider filing a bug report with Debian/Ubuntu if it is their
>> fault.
>>

The problem _is_ rock behaviour. Because it is initializing without
checking for existence. Erasing a working DB if the admin happens to run
squid -z without understanding its full operation.

-z should be able to run at any time without any major consequences.

I am completely in favour of adjusting -z to perform a validate by
default when possible.
However, that does not change the fact that rock is currently performing
an _erase_ operation when one exists.

>>
>> To be consistent with ufs, we should probably change rock behavior from
>> initializing the database to doing nothing if the configured database
>> directory already exists. Like ufs, rock will rely on directory
>> existence for that test (regardless of what may be inside that
>> configured directory). In other words, squid-z is not "validate and
>> initialize" but "initialize if the configured directory is not there".
>>
>>
>> Any objections to that rock change?

Absolutely none. Start by making both perform an existence check before
doing *anything*.
  * initialize if it does not exist yet
  * optionally perform validation + repair if something does.

UFS seems to scan the directory structure and create missing
sub-directories. Omiting the file corruption tests. We should probably
add these now that they are possible.

Rock should probably scan the potentially corrupt database and try to
drop/erase individual corrupt entries before deciding whether to
completely re-initialize the DB.

>
> My starter assumption was that squid -z erase or reset any cache_dir.
> Then I found out it's not like that.
>
> The init scripts checks for directories AND FILES but is not smart
> enough to verify the integrity of the content.
>
> So now the question is:
> If squid has the ability to verify the cache_dir structure and DB more
> then an init script, Why do we even let the script decide this kind of
> decision?

Init scripts do this because Squid crashes on startup if the directories
do not exist, squid-2 packaged with a default cache_dir, and some
systems are automatically built using tools like puppet - drop config
files into /etc/default/$PROG ; install $PROG ; service start $PROG.
Less than 5 minutes from bare metal to operational server.

> Squid in any case rebuilds ufs stores or fix if corrupted or not?? right?

"not". This operation is a todo list entry.

> Why squid should not create a cache_dir if one dosn't exits at startup?
> What side effects can come from that?

>
> It can more complex but a "check", "reset", "build" flags can be added
> to the -z like in -k parse|...|..| while having a default to "build"
> which is what it does's now.
>
> The "build" will be the default and compatible with the current -z
> flag works.
>
> The "check" can respond to an init or any other script a more
> informative way about the check like 1 is bad 2 is something dirty 3
> there is not store present 4 DB corrected.
>
> I just think loudly since the subject was opened.
>
>
Received on Mon Feb 04 2013 - 03:31:11 MST