port LISTEN but no process found

[Heiko_7]

goodmorgning

we are trying to start aan application on an specified port, but that port is already in use.

with netstat we see the port in a LISTEN state

but lsof -i:xxxxxx  shows no sign of this port being in use.

is there someone who can tell me what i'm missing here?

( hpux 11.31 Superdoom )

With kind regards,

Heiko

[Akio Kabutogi]

Can you tell me the port number you see the problem with ?

[Heiko_7]

portnummer is 49232

[Akio Kabutogi]

First, I'd be interested in the patch level you're running. Especially for ARPA/Transport patch.

"swlist -l fileset|grep ARPA" will show. If it shows PHNE_42017, the patch level is the latest.

In that case, the following possibilities could leave such orphaned LISTEN port:

1) The system has a certain kernel intrusive 3rd party modules which may prevent that

     LISTEN port from being released.

2) The system has a certain 3rd party kernel module which spawns a kernel daemon which

     keeps that port open without going through normal socket API.

3) A corner case unknown(new) defect in the kernel may lead to such a situation.

Port number 49232 does not look to be used by any known processes/daemons. That's why

I can not help thinking of a certain 3rd party kernel module.

Anyway,  it looks it's better to involve official support from HP if the patch is recent one

(like PHNE_39xxx or later). I am not aware of such a problem fixed in recent patches. 

It'd be better to open a support call for HP before shutting down the system as that port will

be released while the system's reboot.  Giving investigation without having the chance to collect

data would be very difficult for this kind of cases.

HP's support may have some other tools to give some more investigation though

I am not 100% sure if such tools could get the reason why such a port is left behind.

[Heiko_7]

the patch were having is

PHNE_41714

were gonna log a call with HP now, to see if they can help us solve tis problem

( hopefully without a reboot )

[Denver Osborn]

this doesn't address why netstat would show the port in a listen state while lsof is null, but as a side note I wouldn't use that port if you haven't tuned tcp_smallest_anon_port.  The port you're trying to use falls within the default ephemeral port range on hp-ux (49152-65535)

To check your value... ndd -get /dev/tcp tcp_smallest_anon_port

-denver

[Akio Kabutogi]

"ephemeral port range" will be the range reserved for the client side port.
When client program issues connect() to its server, the system will assign local port from this range

automatically.

Here, we are talking about LISTEN port being occupied by somebody. LISTEN port is assigned by

bind() system call by server side programs. If this is not LISTEN state, then, the port was assigned

from "ephemeral port range". But in this case, the state is LISTEN. Thus, it's apparently occupied

by a certain server side process(or daemon etc). Seeing no owner process for that port is kinda

problematic as the port will not be available for other server programs as long as it's there.

The port may be owned by KRPC (kernel RPC) which is used by ONC(NFS). In this case, lsof would

not show the owner as the owner is the kernel.