On 2/2/2013 5:10 PM, Luciano Ruete wrote:
> Ok, this one is my fault. Debian/Ubuntu init script does a squid -z in a
> pre-start hook if the cache_dir was not initialized. My rock cache_dir
> was already initialized but the script only knows from AUFS and COSS
> because it is ready for squid-3.1 and not for squid-3.2.
>
> Thanks for the answer.
Yes I have seen that and didn't had time to send you a note about it yet.
Since rock is a new type and squid -z reset it even if it's OK.
I think that like in ufs case squid -z should not reset the rock store
file and just recreate it if it's not there.
The reason is to be consistent with ufs and also prevent this kind of
problem.
This should be files as a separated bug.
what I did to CentOS init script is to start with:
CACHE_AUFS_SWAP=`sed -e 's/#.*//g' $SQUID_CONF | \
egrep "^cache_dir (auf|ufs)"| awk '{ print $3 }'`
CACHE_ROCK_SWAP=`sed -e 's/#.*//g' $SQUID_CONF | \
grep "^cache_dir rock"| awk '{ print $3 }'`
And later check a dir or file existence by the store.
This helps the init script to prevent false identification of cache_dir
but not preventing the very wrong squid -z action.
Regards,
-- Eliezer Croitoru http://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer <at> ngtech.co.ilReceived on Sat Feb 02 2013 - 17:03:40 MST
This archive was generated by hypermail 2.2.0 : Sun Feb 03 2013 - 12:00:06 MST