________________________________ From: Amos Jeffries <squid3@xxxxxxxxxxxxx> > > I have only taken a brief look, but so far it looks like the problematic > sockets are not participating in any ICAP activity. Do you see that from the cache.log, or from ":filedescriptors"? If I list my current filedescriptors right now, I get this: # squidclient mgr:filedescriptors | grep "127.0.0.1:1344" 20 Socket 899 25* 10001 127.0.0.1:1344 127.0.0.1 30 Socket 0 71648 72210 127.0.0.1:1344 127.0.0.1 38 Socket 900 0* 2564 127.0.0.1:1344 127.0.0.1 102 Socket 0 67222 67689 127.0.0.1:1344 127.0.0.1 107 Socket 0 102679 203677 127.0.0.1:1344 127.0.0.1 113 Socket 0 67222 67709 127.0.0.1:1344 127.0.0.1 115 Socket 886 0* 2588 127.0.0.1:1344 127.0.0.1 116 Socket 873 25* 10395 127.0.0.1:1344 127.0.0.1 129 Socket 0 114892 144095 127.0.0.1:1344 127.0.0.1 134 Socket 900 25* 8863 127.0.0.1:1344 127.0.0.1 160 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 165 Socket 0 77833 78401 127.0.0.1:1344 127.0.0.1 166 Socket 0 67222 67702 127.0.0.1:1344 127.0.0.1 175 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 176 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 212 Socket 0 67222 67742 127.0.0.1:1344 127.0.0.1 213 Socket 878 0* 2533 127.0.0.1:1344 127.0.0.1 226 Socket 873 0* 2531 127.0.0.1:1344 127.0.0.1 236 Socket 0 78332 180786 127.0.0.1:1344 127.0.0.1 244 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 281 Socket 0 67222 67685 127.0.0.1:1344 127.0.0.1 285 Socket 0 78253 149568 127.0.0.1:1344 127.0.0.1 298 Socket 0 77833 78451 127.0.0.1:1344 127.0.0.1 305 Socket 0 74366 168309 127.0.0.1:1344 127.0.0.1 307 Socket 0 114519 115068 127.0.0.1:1344 127.0.0.1 326 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 327 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 365 Socket 0 70248 114918 127.0.0.1:1344 127.0.0.1 372 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 390 Socket 0 77833 78483 127.0.0.1:1344 127.0.0.1 404 Socket 0 90022 90703 127.0.0.1:1344 127.0.0.1 464 Socket 0 78253 144095 127.0.0.1:1344 127.0.0.1 472 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 480 Socket 891 0* 2514 127.0.0.1:1344 127.0.0.1 491 Socket 0 67222 67685 127.0.0.1:1344 127.0.0.1 509 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 512 Socket 0 67222 67703 127.0.0.1:1344 127.0.0.1 528 Socket 0 131176 155548 127.0.0.1:1344 127.0.0.1 536 Socket 0 70111 134058 127.0.0.1:1344 127.0.0.1 547 Socket 0 67222 67689 127.0.0.1:1344 127.0.0.1 554 Socket 0 131860 152673 127.0.0.1:1344 127.0.0.1 570 Socket 0 67222 67707 127.0.0.1:1344 127.0.0.1 572 Socket 893 0* 2706 127.0.0.1:1344 127.0.0.1 596 Socket 0 78390 114864 127.0.0.1:1344 127.0.0.1 602 Socket 0 67222 67691 127.0.0.1:1344 127.0.0.1 624 Socket 0 72678 73442 127.0.0.1:1344 127.0.0.1 631 Socket 0 71646 72250 127.0.0.1:1344 127.0.0.1 635 Socket 0 104333 104896 127.0.0.1:1344 127.0.0.1 641 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 646 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 662 Socket 0 67222 67698 127.0.0.1:1344 127.0.0.1 674 Socket 0 67222 67691 127.0.0.1:1344 127.0.0.1 678 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 687 Socket 0 67222 67702 127.0.0.1:1344 127.0.0.1 730 Socket 0 67222 67691 127.0.0.1:1344 127.0.0.1 767 Socket 0 74465 152811 127.0.0.1:1344 127.0.0.1 772 Socket 0 67217 67747 127.0.0.1:1344 127.0.0.1 815 Socket 0 77864 78246 127.0.0.1:1344 127.0.0.1 848 Socket 0 67222 67743 127.0.0.1:1344 127.0.0.1 865 Socket 0 67222 67747 127.0.0.1:1344 127.0.0.1 890 Socket 0 67222 67699 127.0.0.1:1344 127.0.0.1 943 Socket 0 77833 78501 127.0.0.1:1344 127.0.0.1 1008 Socket 0 74212 78383 127.0.0.1:1344 127.0.0.1 1018 Socket 0 74466 90630 127.0.0.1:1344 127.0.0.1 1099 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 1124 Socket 0 67222 67683 127.0.0.1:1344 127.0.0.1 1167 Socket 0 67222 67687 127.0.0.1:1344 127.0.0.1 1273 Socket 0 67258 67879 127.0.0.1:1344 127.0.0.1 1337 Socket 0 74243 78265 127.0.0.1:1344 127.0.0.1 Both Nread and Nwrite seem to be well over 0. > That implies they > are possibly TCP connections which never complete their opening > sequence, or at least the result of connection attempts does not make it > back to the ICAP code somehow. ICAP and Squid are both on localhost. I'd like to find out why this is happening. I believe I already posted a tcpdump trace of the ICAP traffic, but I don't know if you had a chance to take a look at it. I had a quick look, but I'm not familiar with the ICAP protocol. In any case, I probably would see a lot of OPTIONS, REQMOD, RESPMOD methods, but I don't know if I would clearly detect initial TCP issues. Anyway, here's a dumb question. Can't Squid "tell" when a TCP connection to an ICAP server has never completed correctly after x timeout, and close it down/reset it? I'm using default values in squid.conf for the following: connect_timeout icap_connect_timeout peer_connect_timeout The docs say: # TAG: icap_connect_timeout # This parameter specifies how long to wait for the TCP connect to # the requested ICAP server to complete before giving up and either # terminating the HTTP transaction or bypassing the failure. BTW I guess it's just a typo error because instead of an "HTTP transaction" I should read "ICAP transaction", right? Anyway, I have "bypass=0" for the ICAP service so I guess it should honor connect_timeout. The default is connect_timeout 1 minute. With a 1-minute timeout it may be hard to see the sockets close when there's plenty of traffic, but I think I should see a substantial drop of open sockets when traffic is low (eg. at night). However, I don't see it. What could I try? Thank you very much for your time. Vieri _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
