Henrik wrote:
> Note: the pid_filename needs to be set the same to make sure you do
> not accidently try to start two different Squid versions at the same
> time.
The opposite (tricking a 2nd copy of squid into running) can be useful too:
Last night I wanted to reinitialize my misconfigured /cache dir but have
minimum downtime for any late night surfers. First I reconfigured cache_dir
to point to a cache I normally don't use (/cache2, just a filesystem on the
OS disk). I then used a custom made squid.conf file that had a bogus path
to the pid file and the correct path to the cache_dir to reinitialize
(/cache on the dedicated disk) and then ran squid -f temp.conf -z. Once it
was done, I edited squid.conf back to point cache_dir to /cache and then
stop and tarted squid. Some downtime but minimal since I could have both
a working/running squid and the initializing squid. Not sure if this is a
"worst practise" or not but it worked for me.
> This also has the benefit that you do not need to change anything when
> temporarily switching Squid version. Just shut down the "old" version
> and then start the "new" by full path.
Excellent idea. Up to now I've just been renaming squid to squid2.#S# and
untarring the dev copy I made. If I had to revert back to the old version,
I would rename squid to squid_bad and then mv squid2.#S# to squid. This way
you don't have to remember what version you are running off of as the
stable/PROD version is always the one in /usr/local/squid. I can see using
your methods on a DEV box but on PROD I'd prefer to keep the final copy in
/usr/local/squid.
thanks again,
Adam
Received on Tue May 06 2003 - 15:36:00 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:16:17 MST