Simpler Navigation for Servers and Operating Systems - Please Update Your Bookmarks
Completed: a much simpler Servers and Operating Systems section of the Community. We combined many of the older boards, so you won't have to click through so many levels to get at the information you need. Check the consolidated boards here as many sub-forums are now single boards.
If you have bookmarked forums or discussion boards in Servers and Operating Systems, we suggest you check and update them as needed.
Networking
cancel
Showing results for 
Search instead for 
Did you mean: 

port LISTEN but no process found

Heiko_7
Advisor

port LISTEN but no process found

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

6 REPLIES

Re: port LISTEN but no process found

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

Heiko_7
Advisor

Re: port LISTEN but no process found

portnummer is 49232

 

Re: port LISTEN but no process found

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
Advisor

Re: port LISTEN but no process found

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
Honored Contributor

Re: port LISTEN but no process found

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

Re: port LISTEN but no process found

"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.