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.
http://wiki.squid-cache.org/SquidFaq/BugReporting#Using_gdb_debugger_on_a_live_proxy_.28with_minimal_downtime.29
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
