Hi all,
I have the same problem, but using Varnish.
I dont think it is an application bug because Poul-Henning Kamp (the
developer of the application) is also a freebsd kernel developper..
# uname -a
FreeBSD cache2 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #0: Thu Jun 19
20:37:34 CEST 2008 [E
Hi Guys,
Another public follow-up: Ali has been sending me debugging information
privately due to the inclusion of application source code and IP
addresses. Tracing of the application suggests that there is an
application concurrency bug leading to one socket to be closed twice and
another so
On Fri, 27 Jun 2008, Robert Watson wrote:
I've asked Ali to do a bit more debugging and tracing of the application to
see if we can reach any conclusions about this. In particular, if he traces
to a file all file descriptor numbers returned by accept(2), then we can
later compare that file wi
On Thu, 26 Jun 2008, Eygene Ryabinkin wrote:
I had already tried to debug this situation and Mike Silbersack
helped me with patching the kernel. At that days his patches (that
went into 7.x) helped, but with higher request rate to the Apache,
they seem to be back again. I can try to setup the
On Fri, 27 Jun 2008, Paul wrote:
I have the same 'problem' if that helps any.. Sockets stuck for over a month
in CLOSED and they have a * for the port on the source IP. tcp4 0 0
67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6:
Thu Apr 17 18:11:49 EDT 2008 amd64 Doesn'
On Fri, 27 Jun 2008, Eygene Ryabinkin wrote:
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
I have the same 'problem' if that helps any.. Sockets stuck for over a
month in CLOSED and they have a * for the port on the source IP. tcp4 0 0
67.1.1.1.* 67.1.1.2.1261 CLOSED 7.0-
Hi Eygene.. It happens with telnet :) A lot of my closed entries are
from telnet so I can't really put a finger on any specific application :/
Eygene Ryabinkin wrote:
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
I have the same 'problem' if that helps any.. Sockets s
Paul, good day.
Fri, Jun 27, 2008 at 08:45:50AM -0400, Paul wrote:
> I have the same 'problem' if that helps any.. Sockets stuck for over a
> month in CLOSED and they have a * for the port on the source IP.
> tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED
> 7.0-RELEASE-p1 Free
I have the same 'problem' if that helps any.. Sockets stuck for over a
month in CLOSED and they have a * for the port on the source IP.
tcp4 0 0 67.1.1.1.* 67.1.1.2.1261 CLOSED
7.0-RELEASE-p1 FreeBSD 7.0-RELEASE-p1 #6: Thu Apr 17 18:11:49 EDT 2008
amd64
Doesn't seem
Ali, good day.
Fri, Jun 27, 2008 at 08:49:20AM +0200, Ali Niknam wrote:
> > Just a quick "me too" message: I also used to see this on my 7.x
> > machines. This was with Apache servers in the proxy setup: one
>
> I'm wondering: where these 32 bit, or 64 bit machines?
amd64.
> > I had already tr
On Thu, 26 Jun 2008, Robert Watson wrote:
I think the first logical step is to wait for the application to get into
that state again, and then run procstat or fstat to dump the file descriptor
away for the process. Presumably in the normal steady state, you expect to
see a few IPC sockets (sy
Hi Eygene,
Just a quick "me too" message: I also used to see this on my 7.x
machines. This was with Apache servers in the proxy setup: one
I'm wondering: where these 32 bit, or 64 bit machines?
I had already tried to debug this situation and Mike Silbersack
helped me with patching the kerne
Good day.
Wed, Jun 25, 2008 at 07:43:12PM +0200, Ali Niknam wrote:
> Recently i've been upgrading some of my machines from FreeBSD 6.x amd64
> to FreeBSD 7.0 amd64.
>
> After upgrading I noticed a weird error/bug. It seems that after several
> thousand TCP connections some seem to hang in 'CLOS
On Wed, 25 Jun 2008, Ali Niknam wrote:
precisely matches that what you'd expect: lots of TCP connections in the
CLOSED state reflecting a series of connections built by an application but
then not properly discarded. Likewise, when the application is killed, all
of the connections go away --
Ali Niknam wrote:
Hi Robert,
[snip]
I will double check this once more, but honestly, i strongly doubt it...
Also one other thing that I've noticed, is that it's always the input
buffer that has bytes left; never the output buffer...
Moreover, i've seen that close() reports EBADF, but du
Hi Robert,
Sounds like there's a bug somewhere. Before we start trying to track it
[...]
So, with that introduction, we're interested in resolving:
Quite comprehensive indeed; thank you for all that information. I was
not aware that there was a decoupling between the various parts of the
On Wed, 25 Jun 2008, Ali Niknam wrote:
Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to
FreeBSD 7.0 amd64.
After upgrading I noticed a weird error/bug. It seems that after several
thousand TCP connections some seem to hang in 'CLOSED' state.
Sounds like there's a
On 6/25/08, Ali Niknam <[EMAIL PROTECTED]> wrote:
> > This looks like an issue we used to have at work, where a streaming
> > application suddenly started getting kevents for sockets that had been
> > already closed. While that was happening, a netstat output looked just
> > like yours. We never
On 6/25/08, Ali Niknam <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> Recently i've been upgrading some of my machines from FreeBSD 6.x amd64 to
> FreeBSD 7.0 amd64.
>
> After upgrading I noticed a weird error/bug. It seems that after several
> thousand TCP connections some seem to hang in 'CLOSED' s
This looks like an issue we used to have at work, where a streaming
application suddenly started getting kevents for sockets that had been
already closed. While that was happening, a netstat output looked just
like yours. We never tracked it down, as we moved to other projects :(
Was that B
Dear All,
Recently i've been upgrading some of my machines from FreeBSD 6.x amd64
to FreeBSD 7.0 amd64.
After upgrading I noticed a weird error/bug. It seems that after several
thousand TCP connections some seem to hang in 'CLOSED' state.
netstat -n gives:
...
tcp4 0 0 1.2.3.4.*
21 matches
Mail list logo
