Re: [squid-users] waiting for Henrick's Reply

Why this warning is shown on some configurations/clients only I don't know.
However, it have turned out the warning maybe wasn't as harmless as it was
supposed to be in the current HEAD version (2.5), possibly causing
connections to hang.

Still, the bug found does not exactly match the error symptoms you have
described. The error symptoms you have described are consistent with a
SYN flood, caused either by a malicious user attacking your server or
improper routing causing replies from Squid to not reach the client.
Without SYN flood protection on the server such situations will cause the
http port to be unreachable for extended periods of time, causing very long
delays until new connections are accepted if at all accepted. However, if
your Squid is experiencing a LOT of these then it may run out of
filedescriptors, causing a similar situation.

If you are running Squid-2.5 then please upgrade to Squid-2.5-20010824 or
later, or apply the attached patch. (upgrading recommended)

--
Henrik Nordstrom
Squid Hacker
MARA Systems AB
Sweden
khiz code wrote:
> Hi henrick
> i had mailed to this saying that both the child and the parent hv debug
> level 2 enabled
> then why is that i get "Resource temporarily available" errors only in
> the child's proxy cache.log file ( where users connect) and not in the
> parent's cache.log file
> btw is this a serious message so as to stall squid from accepting
> further connections under load????
> pls do get back
> i know i m becoming sort of a nuisance to the list ... but there is no
> one else who can possibly help me out !!!!! ;-)
> so waiting for ur replies
> Khiz
>
> --- Henrik Nordstrom <hno@hem.passagen.se> wrote:
> > khiz code wrote:
> >
> > > browser used child proxy as its proxy
> > >  cache.log reports
> > > a > of child proxy
> > >    after almost every request we get the same
> > >  2001/08/21 11:05:56| clientReadRequest: FD 17: no data to process
> > > ((11) Resource
> > >  temporarily unavailable
> > > b> cache.log of parent proxy
> > >  NO SUCH "Resource unavail Messages"
> > > not even once !!!!
> >
> > Not nessesarily. Anyway, as I said the message is fairly expeced, and
> > is
> > only printed if you enable more detailed debugging than the default
> > ALL,1.
> >
> > > under load i cpatured netstat -an
> > > then did grep SYN_RECV | wc -l
> > > the o/p was abt 1024 to 1030
> > > this is at putting the machine atload for not more than 10 mins
> > > does this indicate a SYN flood
> > > do i need to increase tcp_max_syn_backlog in /proc
> > > or do i need to change tcp_syncookies
> >
> > If you have large amounts of SYN_RECV you for sure have a problem
> > with
> > SYNs. Possibilities:
> >
> > a) Someone is SYN flooding your server
> >
> > b) You have some networking problem, causing return traffic for
> > some/many
> > clients to get lost
> >
> > To diagnose further, try to figure out is there is any pattern in the
> > source IP's of the SYN_RECV sockets.
> >
> > --
> > Henrik Nordstrom
> > Squid Hacker
> >
>
> __________________________________________________
> Do You Yahoo!?
> Make international calls for as low as $.04/minute with Yahoo! Messenger
> http://phonecard.yahoo.com/

Index: squid/src/client_side.c
===================================================================
RCS file: /server/cvs-server/squid/squid/src/client_side.c,v
retrieving revision 1.542
diff -u -w -r1.542 client_side.c
--- client_side.c 2001/08/03 15:13:03 1.542
+++ client_side.c 2001/08/24 14:50:56
@@ -2682,7 +2682,7 @@
 {
     ConnStateData *conn = data;
     if (conn->body.size_left)
- return conn->in.offset >= conn->in.size;
+ return conn->in.offset >= conn->in.size - 1;
     else
         return conn->defer.until > squid_curtime;
 }
@@ -2703,6 +2703,7 @@
     fde *F = &fd_table[fd];
     int len = conn->in.size - conn->in.offset - 1;
     debug(33, 4) ("clientReadRequest: FD %d: reading request...\n", fd);
+ commSetSelect(fd, COMM_SELECT_READ, clientReadRequest, conn, 0);
     if (len == 0) {
         /* Grow the request memory area to accomodate for a large request */
         conn->in.size += CLIENT_REQ_BUF_SZ;
@@ -2764,15 +2765,12 @@
             return;
         } else if (conn->in.offset == 0) {
             debug(50, 2) ("clientReadRequest: FD %d: no data to process (%s)\n", fd, xstrerror());
- return;
         }
         /* Continue to process previously read data */
     }
     /* Process request body if any */
     if (conn->in.offset > 0 && conn->body.callback != NULL)
         clientProcessBody(conn);
- if (conn->body.size_left == 0)
- commSetSelect(fd, COMM_SELECT_READ, clientReadRequest, conn, 0);
     /* Process next request */
     while (conn->in.offset > 0 && conn->body.size_left == 0) {
         int nrequests;
@@ -3017,8 +3015,6 @@
             requestUnlink(request); /* Linked in clientReadBody */
         debug(33, 2) ("clientProcessBody: end fd=%d size=%d body_size=%d in.offset=%d cb=%p req=%p\n", conn->fd, size, conn->body.size_left, conn->in.offset, callback, request);
     }
- if (conn->in.offset < conn->in.size - 1 || conn->body.size_left == 0)
- commSetSelect(conn->fd, COMM_SELECT_READ, clientReadRequest, conn, 0);
 }
 
 /* A dummy handler that throws away a request-body */
Received on Fri Aug 24 2001 - 09:36:12 MDT