PHWinfo - Afficher un message - Difficulty identifying what process is causing sockets stuck in SYN_SENT state on host. Also seeing other odd behavior.

01/11/2006, 14h45

Barry Margolin wrote:
> In article <1162306990.563572.18040@m7g2000cwm.googlegroups.c om>,
> phreon@gmail.com wrote:

<CUT>
> > SYN_SENT
> > f1c0e400 tcp 0 0 HOST.3619 *.*
> > SYN_SENT
> > f18ebe00 tcp 0 0 HOST.3619 *.*
> > SYN_SENT
> > f1c0dc00 tcp 0 0 HOST.3608 *.*
> > SYN_SENT
> > f1c0d800 tcp 0 0 HOST.3608 *.*
> > SYN_SENT
> > f18ebc00 tcp 0 0 HOST.3596 *.*
> > SYN_SENT
>
> This doesn't make much sense to me. How can you send a SYN to an
> unspecified remote address and port? The foreign address can only be
> *.* on a LISTENING socket. This smells like an OS bug to me. Have you
> talked to the vendor?
>
> >

Thanks for the corroboration. I thought the above was an example of a
technically impossible state; I like to verify the incredible before
proceeding too far.

Perhaps this is the manifestation of an OS bug, but I haven't gone to
SCO yet. 5.0.5 has been superceded and their standard answer is
usually, "upgrade". If I was talking about a handful of machines, it
would be a "no brainer", but upgrading several hundred 24x7 boxes
scattered across the country is non-trivial. I'm trying to gather as
much ammunition as possible before invoking their tedious support
process.

I know the standard answer should be, "the operating system won't allow
this", but could I be dealing with a server process so poorly written
that it can request a socket for a connection to an unspecified
destination addresses?

<CUT>
>
> When a computer connects to itself, it's normal for them to appear in
> pairs like this. There's one socket in the client process, and another
> socket with the opposite port numbers in the server process. All these
> random port numbers are probably RPC clients and servers.
>

I suspected as much. I still harbor a suspicion because there *appears*
to be a loose correlation between the number of these ESTABLISHED pairs
(and/or the load on the software subsystem they're attached to) and how
quickly our troublesome SYN_SENT sockets grow.

In the short term, we've increased the streams memory on the worst
offenders, but I view this "solution" as akin to slapping a bandage
over a bleeding shotgun wound.

Thanks

01/11/2006, 14h45	#3
phreon@gmail.com Messages: n/a Hébergeur:	Re: Difficulty identifying what process is causing sockets stuck in SYN_SENT state on host. Also seeing other odd behavior. Barry Margolin wrote: > In article <1162306990.563572.18040@m7g2000cwm.googlegroups.c om>, > phreon@gmail.com wrote: <CUT> > > SYN_SENT > > f1c0e400 tcp 0 0 HOST.3619 . > > SYN_SENT > > f18ebe00 tcp 0 0 HOST.3619 . > > SYN_SENT > > f1c0dc00 tcp 0 0 HOST.3608 . > > SYN_SENT > > f1c0d800 tcp 0 0 HOST.3608 . > > SYN_SENT > > f18ebc00 tcp 0 0 HOST.3596 . > > SYN_SENT > > This doesn't make much sense to me. How can you send a SYN to an > unspecified remote address and port? The foreign address can only be > . on a LISTENING socket. This smells like an OS bug to me. Have you > talked to the vendor? > > > Thanks for the corroboration. I thought the above was an example of a technically impossible state; I like to verify the incredible before proceeding too far. Perhaps this is the manifestation of an OS bug, but I haven't gone to SCO yet. 5.0.5 has been superceded and their standard answer is usually, "upgrade". If I was talking about a handful of machines, it would be a "no brainer", but upgrading several hundred 24x7 boxes scattered across the country is non-trivial. I'm trying to gather as much ammunition as possible before invoking their tedious support process. I know the standard answer should be, "the operating system won't allow this", but could I be dealing with a server process so poorly written that it can request a socket for a connection to an unspecified destination addresses? <CUT> > > When a computer connects to itself, it's normal for them to appear in > pairs like this. There's one socket in the client process, and another > socket with the opposite port numbers in the server process. All these > random port numbers are probably RPC clients and servers. > I suspected as much. I still harbor a suspicion because there appears to be a loose correlation between the number of these ESTABLISHED pairs (and/or the load on the software subsystem they're attached to) and how quickly our troublesome SYN_SENT sockets grow. In the short term, we've increased the streams memory on the worst offenders, but I view this "solution" as akin to slapping a bandage over a bleeding shotgun wound. Thanks