You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-users@mina.apache.org by Fred Moore <fr...@gmail.com> on 2008/12/08 20:32:39 UTC
Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Hi,
on linux we noticed that a number of file descriptors associated with
sockets are leaked when using FTP/S TLS/Explicit as we serve connect and
disconnects (and -- possibly - LIST commands returning empty lists)
eventually leading to a "Too Many Files Opened" condition as we hit th 1024
file descriptor limit in /proc.
For each connect/disconnect/list cycle we observe a leak of about 10 socket
file descriptors.
JMAP does not show any unreachable java references, so the problem may
originate deeper, closer to native JVM layers or as a consequence of some
java.nio verb misuse (btw we validated this both on J2SE 5 and J2SE 6).
We detect this by issuing "jmap -histo:live <procid> | grep -i socket" (the
":live" directive selects only live references that would not be garbage
collected).
We are "locked" on revision version 681183 of FTP Server and cannot easily
upgrade right now, moreover we plugged a few custom components (a user
manager, a virtual file system manager and a jce provider) which may or may
not be part of the problem.
Has anyone seen this before?
Can you provide some troubleshooting hints for this kind of problem?
Any help is highly appreciated.
Cheers,
F.
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by David Latorre <dv...@gmail.com>.
Hello Fred,
Let's see Niklas response on this issue cause I haven't experienced this
issue as of now.
Are you experiencing this issue only in SSL mode or is it that you haven't
tested it in plain connections?
What are you using to list the open file descriptors? My knowledge here is
rather limited but using lsof -p <pid> | wc -l doesn't show any increase
in the list when we constantly re-connect. Is this use of lsof valid for
your problem? Can you compare several outputs so we can see what those fd
are?
2008/12/8 Fred Moore <fr...@gmail.com>
> Hi,
>
>
> on linux we noticed that a number of file descriptors associated with
> sockets are leaked when using FTP/S TLS/Explicit as we serve connect and
> disconnects (and -- possibly - LIST commands returning empty lists)
> eventually leading to a "Too Many Files Opened" condition as we hit th 1024
> file descriptor limit in /proc.
>
> For each connect/disconnect/list cycle we observe a leak of about 10 socket
> file descriptors.
>
> JMAP does not show any unreachable java references, so the problem may
> originate deeper, closer to native JVM layers or as a consequence of some
> java.nio verb misuse (btw we validated this both on J2SE 5 and J2SE 6).
>
> We detect this by issuing "jmap -histo:live <procid> | grep -i socket" (the
> ":live" directive selects only live references that would not be garbage
> collected).
>
> We are "locked" on revision version 681183 of FTP Server and cannot easily
> upgrade right now, moreover we plugged a few custom components (a user
> manager, a virtual file system manager and a jce provider) which may or may
> not be part of the problem.
>
> Has anyone seen this before?
> Can you provide some troubleshooting hints for this kind of problem?
>
> Any help is highly appreciated.
> Cheers,
> F.
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Fred Moore <fr...@gmail.com>.
> You're attachments did not get through (Apache mail servers strips
> them). Instead, please open a JIRA issue for this problem and attach
> them there. I will then attempt to reproduce.
...thanks for your feedback (sorry but I was not aware of that).
I just created JIRA issue FTPSERVER-241 "Socket file descriptors leak
leading to 'Too Many Files Open' using FTP/S" with attachments & co.:
https://issues.apache.org/jira/browse/FTPSERVER-241
TIA for your help!
Cheers,
F.
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
You're attachments did not get through (Apache mail servers strips
them). Instead, please open a JIRA issue for this problem and attach
them there. I will then attempt to reproduce.
/niklas
On Fri, Dec 12, 2008 at 7:03 PM, Fred Moore <fr...@gmail.com> wrote:
> Niklas, David, All,
>
> please find attached the following repro/test harness artifacts
>
>
> ====> FDLeakBase.java
>
> Launch this program with the following command line:
>
> java test.FDLeak <home-dir> <time-out-in-minutes> <keystore>
> <keystorepassword>
>
> This is a program that starts an embedded FTP/S Server (M2-ish) and an
> embedded FTP/S Client that pounds it with a tight CONN+NLST+DISC loop.
>
> In our Linux *and* Windows environment we have leaks when run on JRE other
> (newer) than 1.5.0_11.
>
> We monitor leaks using "lsof -p <pid> | grep sock" on Linux, and using
> SysInternals processexplorer on Windows.
>
> FWIW on Windows the leak surfaces as a growing number of process EndPoints
> in processexplorer generated dumps, which seem consistent with the symptom
> reported a while ago here:
> http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg00131.html by
> Gerard Frederic.
>
>
> ====> TestKO.java
>
> Launch this program with the following command line (you should provide a
> selfsigned keystore with related password):
>
> java -cp . -Djavax.net.ssl.keyStore=server.jks
> -Djavax.net.ssl.keyStorePassword=password TestKO
>
> The program will loop over SSLServerSocket createServerSocket()/close() and
> quickly hit the "too many files open" condition very quickly (unless you run
> it on JRE 1.5.0_11).
>
>
> ====> TestOK.java
>
> Launch this program with the following command line (you should provide a
> selfsigned keystore with related password):
>
> java -cp . -Djavax.net.ssl.keyStore=server.jks
> -Djavax.net.ssl.keyStorePassword=password TestOK
>
> This program is functionally equivalent to TestKO, but it's rewritten to use
> just SSLSocket instead of SSLServerSocket.
>
> This proved to be airtight in all 1.5.x 1.6.x JREs we tested.
>
>
> As you see we did not venture into pathing real FTPServer yet.
> Any feedback is appreciated.
> Cheers,
> F.
>
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Fred Moore <fr...@gmail.com>.
Niklas, David, All,
please find attached the following repro/test harness artifacts
====> FDLeakBase.java
Launch this program with the following command line:
java test.FDLeak <home-dir> <time-out-in-minutes> <keystore>
<keystorepassword>
This is a program that starts an embedded FTP/S Server (M2-ish) and an
embedded FTP/S Client that pounds it with a tight CONN+NLST+DISC loop.
In our Linux *and* Windows environment we have leaks when run on JRE other
(newer) than 1.5.0_11.
We monitor leaks using "lsof -p <pid> | grep sock" on Linux, and using
SysInternals processexplorer on Windows.
FWIW on Windows the leak surfaces as a growing number of process EndPoints
in processexplorer generated dumps, which seem consistent with the symptom
reported a while ago here:
http://www.mail-archive.com/ftpserver-users@mina.apache.org/msg00131.html by
Gerard Frederic.
====> TestKO.java
Launch this program with the following command line (you should provide a
selfsigned keystore with related password):
java -cp . -Djavax.net.ssl.keyStore=server.jks
-Djavax.net.ssl.keyStorePassword=password TestKO
The program will loop over SSLServerSocket createServerSocket()/close() and
quickly hit the "too many files open" condition very quickly (unless you run
it on JRE 1.5.0_11).
====> TestOK.java
Launch this program with the following command line (you should provide a
selfsigned keystore with related password):
java -cp . -Djavax.net.ssl.keyStore=server.jks
-Djavax.net.ssl.keyStorePassword=password TestOK
This program is functionally equivalent to TestKO, but it's rewritten to use
just SSLSocket instead of SSLServerSocket.
This proved to be airtight in all 1.5.x 1.6.x JREs we tested.
As you see we did not venture into pathing real FTPServer yet.
Any feedback is appreciated.
Cheers,
F.
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by David Latorre <dv...@gmail.com>.
Hey,
Fred you should try the workaround proposed in security-dev:
In JSSE, you can layer a SSLSocket over an existing Socket. That will
avoid SSLServerSocket creating the dummy Socket that is eventually
leaking the file descriptors.
ServerSocket ss = new ServerSocket(port);
> Socket s = ss.accept();
> sslssf.createSocket(s, s.getInetAddress().getHostName(),
> s.getPort(), false);
and see if this solves your issue. The simplest thing I can think of is that
you try the provided test case and then the proposed workaround. If this
solves your issue, we might want to implement this as the standard
mechanism to create SSLServerSockets as the JVM creates "dummy" sockets
anyway.
2008/12/11 Niklas Gustavsson <ni...@protocol7.com>
> Hey
>
> That bug seems pretty much exactly describing your problem. Can I make
> some assumptions, please verify them:
> * You only get this when running in passive mode
> * You get the same problem doing a connect -> STOR -> disconnect
> * You get the same problem doing a connect -> RETR -> disconnect
>
> Also, and this is kind of important, your wrote in your first email
> that your listing returned an empty list. Is this always the case? Do
> you see the leak when returning a non-zero size list?
>
> Looking at the workaround, we could certainly attempt using it, but
> first I would like to replicate the problem so we'll know the
> workaround will work for us. I'm on:
> $ java -version
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
>
> $ uname -a
> Linux niklas-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC
> 2008 i686 GNU/Linux
>
> So, I should be affected. Would you be able to share the client test
> script you got?
>
> /niklas
>
> On Thu, Dec 11, 2008 at 8:51 PM, Fred Moore <fr...@gmail.com>
> wrote:
> > Niklas, David, All,
> >
> > here is an update on the problem we reported... more to come as we
> complete
> > some additional tests tomorrow any HELP is welcome!
> >
> > During the last few days we kept narrowing down the debug scenario in
> order
> > to have a more precise idea of this blocking problem shape & scope.
> >
> > Here are a few findings:
> >
> > 1\ KO on Linux with Sun HotSpot J2SE 1.5.0_12 or higher
> >
> > 2\ KO on Linux with Sun HotSpot J2SE 1.6.0_xx
> >
> > 3\ OK on Linux with Sun HotSpot J2SE 1.5.0_11
> >
> > 4\ KO on Windows with Sun HotSpot J2SE 1.5.0_15 or higher
> > (procexplorer is showing a growing number of "File \Device\Afd\Endpoint"
> > which eventually will hit the max number in Windows too)
> >
> > 5\ ?? on Windows with Sun HotSpot J2SE 1.5.0_11 (will test this tomorrow
> to
> > ensure this JVM version is as safe on Windows as it is on Linux)
> >
> >
> > The "too many files open" condition (or its Windows variant) is hit when
> we
> > repeat a Connect, ListNames (NLST), Disconnect in a tight loop for about
> 1
> > hour, over FTP/S TLS/Explicit.
> >
> > Please notice that these other scenarios are OK:
> >
> > A\ Just connecting/disconnecting without issuing the NLST command
> >
> > B\ Using straight FTP connection
> >
> >
> > The FTPServer codebase used for the test was M2-level with still some
> custom
> > code (we had no time so far to setup a "clean" M4 env), but we still
> believe
> > that the custom code is not related with the reported problem (and it's
> > difficult to quickly evict it in our environment right now).
> >
> > We currently believe to have incurred in this JVM bug "SSLServerSocket
> file
> > descriptor leak":
> > http://bugs.sun.com/view_bug.do?bug_id=6764972 :
> >
> > ---begin---
> > File descriptors of TCP sockets are not released properly when using
> > SSLServerSocket class ( especially with many instances ) on Linux
> systems.
> >
> > If a server application ( like Jakarta Tomcat ) runs very long time,
> > this problem will cause a 'too many open files' error and a denial of
> > the service.
> > ---end---
> >
> >
> > Given your very detailed knowledge of FTPServer source code and bug
> 6764972
> > description, do you think this might be the case?
> > Can you suggest any patch / workaround for that?
> >
> > Any help at this stage is highly appreciated!
> > Cheers,
> > F.
> >
> > PS: speaking of workarounds this thread may/may not be relevant for the
> case
> > at hand (look up "leak" & "layer" keywords):
> >
> http://www.nabble.com/-security-dev-00402-:-Re:-NullPointerException-at%09sun.security.ssl.OutputRecord.writeBuffer-td20492154.html
> >
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
Hey
That bug seems pretty much exactly describing your problem. Can I make
some assumptions, please verify them:
* You only get this when running in passive mode
* You get the same problem doing a connect -> STOR -> disconnect
* You get the same problem doing a connect -> RETR -> disconnect
Also, and this is kind of important, your wrote in your first email
that your listing returned an empty list. Is this always the case? Do
you see the leak when returning a non-zero size list?
Looking at the workaround, we could certainly attempt using it, but
first I would like to replicate the problem so we'll know the
workaround will work for us. I'm on:
$ java -version
java version "1.6.0_10"
Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
$ uname -a
Linux niklas-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC
2008 i686 GNU/Linux
So, I should be affected. Would you be able to share the client test
script you got?
/niklas
On Thu, Dec 11, 2008 at 8:51 PM, Fred Moore <fr...@gmail.com> wrote:
> Niklas, David, All,
>
> here is an update on the problem we reported... more to come as we complete
> some additional tests tomorrow any HELP is welcome!
>
> During the last few days we kept narrowing down the debug scenario in order
> to have a more precise idea of this blocking problem shape & scope.
>
> Here are a few findings:
>
> 1\ KO on Linux with Sun HotSpot J2SE 1.5.0_12 or higher
>
> 2\ KO on Linux with Sun HotSpot J2SE 1.6.0_xx
>
> 3\ OK on Linux with Sun HotSpot J2SE 1.5.0_11
>
> 4\ KO on Windows with Sun HotSpot J2SE 1.5.0_15 or higher
> (procexplorer is showing a growing number of "File \Device\Afd\Endpoint"
> which eventually will hit the max number in Windows too)
>
> 5\ ?? on Windows with Sun HotSpot J2SE 1.5.0_11 (will test this tomorrow to
> ensure this JVM version is as safe on Windows as it is on Linux)
>
>
> The "too many files open" condition (or its Windows variant) is hit when we
> repeat a Connect, ListNames (NLST), Disconnect in a tight loop for about 1
> hour, over FTP/S TLS/Explicit.
>
> Please notice that these other scenarios are OK:
>
> A\ Just connecting/disconnecting without issuing the NLST command
>
> B\ Using straight FTP connection
>
>
> The FTPServer codebase used for the test was M2-level with still some custom
> code (we had no time so far to setup a "clean" M4 env), but we still believe
> that the custom code is not related with the reported problem (and it's
> difficult to quickly evict it in our environment right now).
>
> We currently believe to have incurred in this JVM bug "SSLServerSocket file
> descriptor leak":
> http://bugs.sun.com/view_bug.do?bug_id=6764972 :
>
> ---begin---
> File descriptors of TCP sockets are not released properly when using
> SSLServerSocket class ( especially with many instances ) on Linux systems.
>
> If a server application ( like Jakarta Tomcat ) runs very long time,
> this problem will cause a 'too many open files' error and a denial of
> the service.
> ---end---
>
>
> Given your very detailed knowledge of FTPServer source code and bug 6764972
> description, do you think this might be the case?
> Can you suggest any patch / workaround for that?
>
> Any help at this stage is highly appreciated!
> Cheers,
> F.
>
> PS: speaking of workarounds this thread may/may not be relevant for the case
> at hand (look up "leak" & "layer" keywords):
> http://www.nabble.com/-security-dev-00402-:-Re:-NullPointerException-at%09sun.security.ssl.OutputRecord.writeBuffer-td20492154.html
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Fred Moore <fr...@gmail.com>.
Niklas, David, All,
here is an update on the problem we reported... more to come as we complete
some additional tests tomorrow any HELP is welcome!
During the last few days we kept narrowing down the debug scenario in order
to have a more precise idea of this blocking problem shape & scope.
Here are a few findings:
1\ KO on Linux with Sun HotSpot J2SE 1.5.0_12 or higher
2\ KO on Linux with Sun HotSpot J2SE 1.6.0_xx
3\ OK on Linux with Sun HotSpot J2SE 1.5.0_11
4\ KO on Windows with Sun HotSpot J2SE 1.5.0_15 or higher
(procexplorer is showing a growing number of "File \Device\Afd\Endpoint"
which eventually will hit the max number in Windows too)
5\ ?? on Windows with Sun HotSpot J2SE 1.5.0_11 (will test this tomorrow to
ensure this JVM version is as safe on Windows as it is on Linux)
The "too many files open" condition (or its Windows variant) is hit when we
repeat a Connect, ListNames (NLST), Disconnect in a tight loop for about 1
hour, over FTP/S TLS/Explicit.
Please notice that these other scenarios are OK:
A\ Just connecting/disconnecting without issuing the NLST command
B\ Using straight FTP connection
The FTPServer codebase used for the test was M2-level with still some custom
code (we had no time so far to setup a "clean" M4 env), but we still believe
that the custom code is not related with the reported problem (and it's
difficult to quickly evict it in our environment right now).
We currently believe to have incurred in this JVM bug "SSLServerSocket file
descriptor leak":
http://bugs.sun.com/view_bug.do?bug_id=6764972 :
---begin---
File descriptors of TCP sockets are not released properly when using
SSLServerSocket class ( especially with many instances ) on Linux systems.
If a server application ( like Jakarta Tomcat ) runs very long time,
this problem will cause a 'too many open files' error and a denial of
the service.
---end---
Given your very detailed knowledge of FTPServer source code and bug 6764972
description, do you think this might be the case?
Can you suggest any patch / workaround for that?
Any help at this stage is highly appreciated!
Cheers,
F.
PS: speaking of workarounds this thread may/may not be relevant for the case
at hand (look up "leak" & "layer" keywords):
http://www.nabble.com/-security-dev-00402-:-Re:-NullPointerException-at%09sun.security.ssl.OutputRecord.writeBuffer-td20492154.html
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by David Latorre <dv...@gmail.com>.
Hello Randy,
I am using FTPServer embedded in glassfish with two listeners (implicit ssl
& explicit ssl/plain - although we forbid plain connections) and we are not
seeing this issue.
Since it is two of you already reporting this problem can you please
elaborate a little more on :
- Operating sytem and architecture (we are using CentOS 5.1 and RedHat
under Intel Xeon 64 bits)
- Java version ( 1.6.10 64 bits here).
- Any important modifications/additions to FTPServer?
Besides it would be great if you could test your setup using implicit ssl
instead of explicit, or only plain connections. Maybe it would help that
your tests were based on a 'minimalistic' fresh copy of FTPServer, so we can
trace this.
2008/12/9 Randy Prager <ra...@gmail.com>
> I think we are seeing something similar.
>
> We have 2 instances of FTPServer running, one embedded in tomcat and one in
> its own JVM.
>
> Both appear to hold onto socket descriptors (lsof reports "can't iden
> protocol") ... eventually leading to
> too many open files.
>
> We are continuing to investigate to confirm it is an FTP server issue.
> This
> problem has only occurred recently
> and we suspect it is the result of a new pattern of client connections or
> connection type (we support both FTP and FTP-TLS).
>
> We are not sure why lsof would report the "can't iden protocol" as opposed
> to TCP ...
>
> Our environment is LINUX SLES-10 J2SE 1.6.
>
> Here is a sample config:
>
> <listeners>
> <nio-listener
> name="default"
> port="XXXX"
> implicit-ssl="false"
> idle-timeout="60"
> local-address="XXXXX">
> <ssl>
> <keystore file="classpath:XXXXX.jks" password="XXXXX"/>
> </ssl>
> <data-connection idle-timeout="60">
> <active enabled="false" local-address="XXXXX"
> local-port="XX/>
> <passive ports="XXXXX" address="XXXXX"
> external-address="XXXX"/>
> </data-connection>
> <blacklist>
> </blacklist>
> </nio-listener>
> </listeners>
>
> - Randy
>
> On Tue, Dec 9, 2008 at 10:18 AM, Niklas Gustavsson <niklas@protocol7.com
> >wrote:
>
> > On Mon, Dec 8, 2008 at 8:32 PM, Fred Moore <fr...@gmail.com>
> wrote:
> > > on linux we noticed that a number of file descriptors associated with
> > > sockets are leaked when using FTP/S TLS/Explicit as we serve connect
> and
> > > disconnects (and -- possibly - LIST commands returning empty lists)
> > > eventually leading to a "Too Many Files Opened" condition as we hit th
> > 1024
> > > file descriptor limit in /proc.
> >
> > To make sure I understand you correctly:
> > * Do you only see this when running in SSL/TLS explicit mode? If
> > running without SSL/TLS or in implicit mode, do you get the same
> > behavior?
> > * You only see this when doing LIST? If you only do
> > connect->disconnect, you don't get the problem? If doing a STOR or
> > RETR, do you get the problem?
> > * Do you only get the problem when returning an empty LIST?
> >
> > [snip]
> >
> > > Has anyone seen this before?
> >
> > Not really no, but I haven't really pushed it on very specific cases
> > like this. However, if we can nail it down to a repeatable test case,
> > I'm willing to try debugging it.
> >
> > /niklas
> >
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Randy Prager <ra...@gmail.com>.
I think we are seeing something similar.
We have 2 instances of FTPServer running, one embedded in tomcat and one in
its own JVM.
Both appear to hold onto socket descriptors (lsof reports "can't iden
protocol") ... eventually leading to
too many open files.
We are continuing to investigate to confirm it is an FTP server issue. This
problem has only occurred recently
and we suspect it is the result of a new pattern of client connections or
connection type (we support both FTP and FTP-TLS).
We are not sure why lsof would report the "can't iden protocol" as opposed
to TCP ...
Our environment is LINUX SLES-10 J2SE 1.6.
Here is a sample config:
<listeners>
<nio-listener
name="default"
port="XXXX"
implicit-ssl="false"
idle-timeout="60"
local-address="XXXXX">
<ssl>
<keystore file="classpath:XXXXX.jks" password="XXXXX"/>
</ssl>
<data-connection idle-timeout="60">
<active enabled="false" local-address="XXXXX"
local-port="XX/>
<passive ports="XXXXX" address="XXXXX"
external-address="XXXX"/>
</data-connection>
<blacklist>
</blacklist>
</nio-listener>
</listeners>
- Randy
On Tue, Dec 9, 2008 at 10:18 AM, Niklas Gustavsson <ni...@protocol7.com>wrote:
> On Mon, Dec 8, 2008 at 8:32 PM, Fred Moore <fr...@gmail.com> wrote:
> > on linux we noticed that a number of file descriptors associated with
> > sockets are leaked when using FTP/S TLS/Explicit as we serve connect and
> > disconnects (and -- possibly - LIST commands returning empty lists)
> > eventually leading to a "Too Many Files Opened" condition as we hit th
> 1024
> > file descriptor limit in /proc.
>
> To make sure I understand you correctly:
> * Do you only see this when running in SSL/TLS explicit mode? If
> running without SSL/TLS or in implicit mode, do you get the same
> behavior?
> * You only see this when doing LIST? If you only do
> connect->disconnect, you don't get the problem? If doing a STOR or
> RETR, do you get the problem?
> * Do you only get the problem when returning an empty LIST?
>
> [snip]
>
> > Has anyone seen this before?
>
> Not really no, but I haven't really pushed it on very specific cases
> like this. However, if we can nail it down to a repeatable test case,
> I'm willing to try debugging it.
>
> /niklas
>
Re: Socket file descriptors leak leading to "Too Many Files Opened" using FTP/S on Linux?
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, Dec 8, 2008 at 8:32 PM, Fred Moore <fr...@gmail.com> wrote:
> on linux we noticed that a number of file descriptors associated with
> sockets are leaked when using FTP/S TLS/Explicit as we serve connect and
> disconnects (and -- possibly - LIST commands returning empty lists)
> eventually leading to a "Too Many Files Opened" condition as we hit th 1024
> file descriptor limit in /proc.
To make sure I understand you correctly:
* Do you only see this when running in SSL/TLS explicit mode? If
running without SSL/TLS or in implicit mode, do you get the same
behavior?
* You only see this when doing LIST? If you only do
connect->disconnect, you don't get the problem? If doing a STOR or
RETR, do you get the problem?
* Do you only get the problem when returning an empty LIST?
[snip]
> Has anyone seen this before?
Not really no, but I haven't really pushed it on very specific cases
like this. However, if we can nail it down to a repeatable test case,
I'm willing to try debugging it.
/niklas