Anton VG wrote:
Will try it now... already compiling.
btw, just looking at the debugging options - i'm going to compile
squid with the following options:
./configure --prefix=/usr/local/squid31trunk --enable-snmp
--enable-storeio=coss,ufs,aufs --enable-coss-aio-ops --with
-coss-membuf-size=10485760 --with-large-files --with-maxfd=65535
--enable-linux-netfilter --disable-optimizations --di
sable-inline --enable-debug-cbdata
would this be ok to compile enough debug info, or you would suggest
something else?
Sounds good for the trace. For cache.log at least:
debug_option ALL,1 85,9
I'm going to attach to a process by gdb and see when it dies,
Any suggestions?
FWIW: COSS in 3.x is known to have bugs. But thats another issue.
I normally run with the gdb commands file containing:
"
set args -ND -f /src/test/squid.conf
file /usr/local/squid/sbin/squid
# handle all nostop print
handle SIGPIPE pass nostop noprint
handle SIGSEGV stop
handle SIGABRT stop
run
backtrace
"
the handle lines are important to tell gdb to ignore the signals squid
sends itself at times.
If you use this, you may need to add the break commands to stop it at
the desired places.
2008/5/20 Amos Jeffries <[EMAIL PROTECTED]>:
Anton VG wrote:
Dear Amos,
Thank you for reply!
2008/5/20 Amos Jeffries <[EMAIL PROTECTED]>:
Anton V.G. wrote:
Extra feedback
started
This one does appear to be a fatal condition occuring. If you can track
it
in gdb or such debugger and get a stack trace of where its happening that
would be a great help.
Can we force it to generate a core? If not, I'll try to debug it.
IPInterception.cc(169) NetfilterTransparent: NF
getsockopt(IP_TRANSPARENT) failed: (92) Protocol not
available
This is bad. It means the TPROXY target is not working in your kernel.
That said squid should at least be handling it well.
It working, but partially, it gives this notice once in ~20 requests,
seems normal requests is in the access.log
Thats normal 'failure' behaviour. Squid has a semi-quiet counter to suppress
a most of those transparency errors so the log does not fill up too quickly.
If its happening that often its safe to assume its always failing.
The only unexpected behaviour there is that the first bind failed with
the
error it gave.
Only you are in a position to say if 82.198.21.17:4008 was the squid
IP:random-port or if it somehow got the client IP and failed when using
that.
It means it really tries to occupy the same port as the user connection?
It should be using another random out port I think. Which gives me an idea
of whats going on.
Does the bind issue disappear if you make this change:
=== modified file 'src/IPInterception.cc'
--- src/IPInterception.cc 2008-04-11 03:33:42 +0000
+++ src/IPInterception.cc 2008-05-20 15:47:17 +0000
@@ -176,6 +176,9 @@
dst.FreeAddrInfo(lookup);
+ /* ignore the port returned in dst. We won't be re-using that exact
one. */
+ dst.SetPort(0);
+
if(me != dst) {
debugs(89, 5, HERE << "address: " << dst);
return 0;
We first need to determine if 82.198.21.17:4008 was valid, and why its
being
used.
If you are up for some code delving we can work this out.
I'll happily do what required! Just need to be guided a little.
If more rapid communication is needed I'm available at google jabber
(the same email) or ICQ 38119392
Amos
--
Please use Squid 2.6.STABLE20 or 3.0.STABLE5
--
Please use Squid 2.6.STABLE20 or 3.0.STABLE5
