On 10.07.2012 09:58, Will Roberts wrote:
> On 07/09/2012 02:18 AM, Alan wrote:
>> A quick search suggest that you are using some kernel security crap,
>> I
>> don't know much about it but try this:
>> echo 0 > /proc/sys/kernel/yama/ptrace_scope
>> Or simply start squid from gdb instead of attaching to the existing
>> process.
>
> Alan,
>
> I believe I stumbled across that earlier, unfortunately that key
> doesn't exist on my system. I am able to strace/gdb right now when my
> squid isn't stuck, so I've attached via gdb and then left it running
> in screen. Hopefully next time it breaks I'll be able to get back in
> and grab a useful stack.
>
> Thanks for the suggestion.
>
> --Will
This debugging script should help there. It ensures almost zero
downtime for clients while debugging a crash on a production machine.
Essentially it grabs the debug traces and restarts squid on every
crash, leaving you a set of GDB reports about the problem. If you can
ensure cores are left on the system you can use those reports and go
back for more data.
Amos
Received on Mon Jul 09 2012 - 23:04:28 MDT
This archive was generated by hypermail 2.2.0 : Tue Jul 10 2012 - 12:00:02 MDT