Re: [squid-users] SMP-Rock-frequent FATAL: Received Segment Violation...dying."only on kid3"

On 2013-11-19 08:09, Dr.x wrote:
> hi ,
>
> i have smp with config as below :
> ###########SMP oPTIONS#####################
> dns_v4_first on
> workers 3
> ########################################################
> cpu_affinity_map process_numbers=1,2,3,4 cores=2,4,6,8
> ======================================
> cache_dir rock /CACHE1 20000 max-size=32768 swap-timeout=350
> max-swap-rate=350
> cache_dir rock /CACHE2 20000 max-size=32768 swap-timeout=350
> max-swap-rate=350
> ==================================================================
> *to be honest , i did alot of killall -9 squid while squid was starting
> and
> building files !!!!!*
> and just addedd directive logfile_rotate 0
> that wt i remebers before i saw that new error in cache.log !!!
>
>
> but today after that modification i see alot of "FATAL: Received
> Segment
> Violation...dying."
> especially for kid 3 !!!!!
> and seems that kid 3 killed then started agian , killed then started
> again
> and so on .
> dont know shoulld i remove logrotate directive , or may the rock db
> damaged and cause this dying signal ???!!!

Either event may have corrupted it slightly. Squid is supposed to
contain sufficient checksum protection in rock to cope with most forms
of corruption, but nobody's perfect.

So, please try to get a core dump, or stack trace of the problem before
going any further. This will help us to isolate where the problem is
occuring. If it is corruption related we will be needing to try and add
better protection for that case.

*after* that, please try:

* shutting Down your Squid by any means necessary to ensure there are 0
processes running.
* *move* the caches to somewhere they can be analysed later if
necessary.
* rebuild the configured cache_dir with squid -z
* wait until -z process completed *AND* there are 0 processes still
running in the background
* restart the main Squid

This entire process should not take more than a minute.

If the problem remains after doing that you will have successfully
eliminated cache corruption as a cause and we go back to needing a
backtrace to figure it out.

Amos
Received on Mon Nov 18 2013 - 22:55:01 MST