Return-Path: Delivered-To: apmail-apache-bugdb-archive@apache.org Received: (qmail 31673 invoked by uid 500); 31 Jul 2001 16:30:01 -0000 Mailing-List: contact apache-bugdb-help@apache.org; run by ezmlm Precedence: bulk Reply-To: apache-bugdb@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-bugdb@apache.org Received: (qmail 31655 invoked by uid 501); 31 Jul 2001 16:30:00 -0000 Date: 31 Jul 2001 16:30:00 -0000 Message-ID: <20010731163000.31654.qmail@apache.org> To: apache-bugdb@apache.org Cc: apache-bugdb@apache.org, From: "Tom Grindrod" Subject: RE: config/8107: Apache keeping files open to long Reply-To: "Tom Grindrod" The following reply was made to PR config/8107; it has been noted by GNATS. From: "Tom Grindrod" To: "'Marc Slemko'" Cc: Subject: RE: config/8107: Apache keeping files open to long Date: Tue, 31 Jul 2001 12:43:20 -0400 This may help.. netstat -n -a -udp | grep httpd | grep 10971 This command shows the sockets open on my web server for a single process and the calling machine which is a named server. Could this be a virtual host issue? Here is the listing for one Apache process. ( there are a hundred more lines like this that correspond to an open stream. 192.67.184.65:53 is the name server. 192.67.184.5 is the web server, so it is opening ports constantly for the named server it lookes like. Port 53 is the udp domain port which maps to our domain: omg.org. I do have 60 or so virstual hosts set up in Apache and wonder if this is somehow related. I don't agree that this in not an Apache problem. I only have this problem with Apache processes and this is not related to any module. Clearly it is something with apache doing a domain lookup. Still I don't know why they don't go away or how apache determines that. Perhaps there is a way to time out these calls to the name server? Below this output, is the output from isof that I forgot so send in my last mail. I don't mean to harp, but this really looks like apache to me. Please send Ideas/commnents. Thanks for helping out. udp 0 0 192.67.184.5:3255 192.67.184.65:53 ESTABLISHED 10971/httpd udp 0 0 192.67.184.5:2897 192.67.184.65:53 ESTABLISHED 10971/httpd udp 0 0 192.67.184.5:2354 192.67.184.65:53 ESTABLISHED 10971/httpd udp 0 0 192.67.184.5:2078 192.67.184.65:53 ESTABLISHED 10971/httpd udp 0 0 192.67.184.5:3231 192.67.184.65:53 ESTABLISHED ISOF output (forgot to send in last mail) I look at the contents of one of the Apache process directories that is growing. cd /proc/10971/fd and get a listing of what is open. i.e : lrwx------ 1 root root 64 Jul 31 09:33 60 -> socket:[218140] I now run isof -c http | grep 218140 to find the corresponing entry. httpd 10971 root 60u IPv4 218140 UDP petros.omg.org:3255->emerald.omg.org:domain -----Original Message----- From: Marc Slemko [mailto:marcs@znep.com] Sent: Tuesday, July 31, 2001 11:59 AM To: Tom Grindrod Cc: apbugs@apache.org Subject: RE: config/8107: Apache keeping files open to long On Tue, 31 Jul 2001, Tom Grindrod wrote: > I ran lsof with the -c option ( allows you to choose a process to look at to > see what it has open). Then I grepped for one Apache process that had over a > hundred files open. Below is the output. The sockets seem to refer to a > second machine that I have mounted to it called emerald. The web server > petros is mounted to emerald. It seems to have many ports open pointing to > emerald via sockets. Not sure what this means, but I feel I am getting > closer. Doesn't look like a module problem though. Any thoughts?? I don't see any output below... The port numbers being used would possibly tell a lot more. But since Apache has no reason to know about or even think about opening such sockets, there isn't much I can say... could well be some module or some OS library. Look very carefully at every dependency that you have between the two machines to see what could be happening...x > > Thanks > -Tom > > -----Original Message----- > From: Marc Slemko [mailto:marcs@znep.com] > Sent: Monday, July 30, 2001 9:57 PM > To: Tom Grindrod > Cc: apbugs@apache.org > Subject: RE: config/8107: Apache keeping files open to long > > > On Mon, 30 Jul 2001, Tom Grindrod wrote: > > > I ran lsof and below a partial listing. Anyone know how to interpret this > so > > as to find what is creating the socket??? Looks French to me. > > grumble. silly linux. > > you could try installing a fresh versoin of lsof, since it "should" be > able to do that itself on many OSes, including Linux I thought... > > Or see if netstat -p outputs anything useful. > > Or see if you can match up any of the numbers in /proc/net/tcp with the > "e5e57480", etc. in 0xe5e57480, then deciper the addresses and ports from > their hex representation.... > > But I'm afraid I'm not a linux expert... > > > > > > > > > httpd 2333 2294 root 10u unix 0xe5e57480 65946 socket > > httpd 2335 2294 root 9u unix 0xe5adabc0 66478 socket > > httpd 2336 2294 root 37u unix 0xe6011600 49563 socket > > httpd 2337 2294 root 5u unix 0xebb0c840 37746 socket > > httpd 2341 2294 root 11u unix 0xe5bed3c0 78367 socket > > httpd 2342 2294 root 7u unix 0xe5adbc40 55195 socket > > > > -----Original Message----- > > From: Marc Slemko [mailto:marcs@znep.com] > > Sent: Monday, July 30, 2001 3:34 PM > > To: Tom Grindrod > > Cc: Apache bugs database > > Subject: RE: config/8107: Apache keeping files open to long > > > > > > On 30 Jul 2001 slive@apache.org wrote: > > > > > The following reply was made to PR config/8107; it has been noted by > > GNATS. > > > > > > From: > > > To: Tom Grindrod > > > Cc: > > > Subject: RE: config/8107: Apache keeping files open to long > > > Date: Mon, 30 Jul 2001 12:17:21 -0700 (PDT) > > > > > > As I mentioned, the next step is to upgrade to the latest > > > version of Apache 1.3. > > > > > > I hate to pass the buck, but I suspect this problem is > > > caused by a third-party module, since we know that > > > Apache doesn't leak descriptors in general. It appears > > > that you are using an SSL module which is one place > > > to look. > > > > I definitely agree with this... it is very unlikely that it is > > Apache itself causing this problem, since someone else would be > > seeing it if it were. You may want to run lsof on some of the httpd > > processes to get a better idea of exactly what these sockets are, > > which can help you figure out what is the real cause. > > > > > > > >