Anton V.G. wrote:
Extra feedback
With the load of ~20 req/sec i'm getting the following in
the syslog. Children processes crashing?
Looks that way.
Lets analyse these in order....
May 19 22:57:08 cacheng squid[15133]: Squid Parent: child
process 15401 exited due to signal 6 with status 0
May 19 22:57:11 cacheng squid[15133]: Squid Parent: child
process 31190 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.
On Monday 19 May 2008 21:41, Anton wrote:
Dear Developers,
Just installed Linux 2.6.24 with TPROXY support and fresh
squid 3.1 (bzr) - TPROXY works, but there are problems
one of several requests endup with error binding to a
socket, with the folloing in the syslog Would like to add
that I do use squid on the latent link (satellite) and
that may matter, since netsoket lives longer, so less
test needed to achieve this error:
May 19 21:02:50 cacheng squid[26551]:
IPInterception.cc(136) NetfilterInterception: NF
getsockopt(SO_ORIGINAL_DST) failed: (11) Resource
temporarily unava
Expected in a TPROXY setup (this is the REDIRECT target being tested). I
still have to work out a good solution to debugging the failovers.
>> May 19 21:02:50 cacheng squid[26551]:
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.
>> May 19 21:02:57 cacheng squid[26551]: commBind:
Cannot bind socket FD 55 to 82.198.21.17:4008: (98)
Address already in use
Um....
>> May 19 21:02:57 cacheng
squid[26551]: comm.cc(993) commResetFD: bind: (98)
Address already in use
Failover handler kicked in after the initial bind and it failed as well.
>> May 19 21:02:57 cacheng
squid[26551]: commBind: Cannot bind socket FD 55 to
82.198.21.17:5407: (98) Address already in use
May 19
21:02:57 cacheng squid[26551]: comm.cc(993) commResetFD:
bind: (98) Address already in use
... and the connection was retried later. These are expected until the
configured timeout occurs and an error page is given to the client. As
seen below ...
and the corresponding site in the browser has the
following (until you refresh)
ERROR
The requested URL could not be retrieved
.(skipped)
The system returned:
(99) Cannot assign requested address
Your cache administrator is webmaster.
Generated Mon, 19 May 2008 16:13:46 GMT by
(squid/3.HEAD-BZR)
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.
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.
Amos
--
Please use Squid 2.6.STABLE20 or 3.0.STABLE5
