Regarding lsof output

[Sunil Surve]

Hello,

I am running lsof on HP-UX 11i system for finding out info for a particular port. I get the output as shown below -

aravali:>/aravali/users/sysadmin#./lsof | grep 6668
unix_vb 2187 idxmgr 5u inet 0x4f06ecc0 0t0 TCP *:6668 (LISTEN)
java 4004 idxmgr 5u inet 0x4f06ecc0 0t0 TCP *:6668 (LISTEN)
java 4007 idxmgr 5u inet 0x4f06ecc0 0t0 TCP *:6668 (LISTEN)
index_sen 4062 idxmgr 5u inet 0x4f06ecc0 0t0 TCP *:6668 (LISTEN)
surv_feed 4063 idxmgr 5u inet 0x4f06ecc0 0t0 TCP *:6668 (LISTEN)

Now, in this case, the process unix_vb actually creates the socket which listens on port 6668. The other processes are not at all related to this process and they are started independently. Why does lsof show so many processes using that port? Further, if the process unix_vb is killed and the other processes are still running I am not able to create a socket again which listens on the same port. It gives error (binding failed).

Thnks and Rgds,

[RAC_1]

I am confused. Can you run following commands.

lsof -p tcp:6668
lsof -p udp:6668

Anil

[Muthukumar_5]

why you are using lsof with grep there?

lsof is designed with some options to do requirements directly.

use lsof -p there.


HTH.

[Sunil Surve]

Hello,

I ran lsof -i tcp:6668 and lsof -i udp:6668 (the version of lsof that i use has -i option for specifyin port number...) . Still it gives the same output. All of them are TCP ports only.

Thnks & Rgds

[Stuart Whitby]

The next argument specified with lsof -p would be a process ID, not a port number. As can be seen by Sunil's follow up post, you get exactly the same info by using grep - simply questioning the efficiency of the way Sunil runs lsof doesn't help solve the problem.

There are a few ways that you'd normally see multiple processes listening on the same port. Most common is that you've got multiple IP addresses configured, such as if you were hosting multiple websites from the same server. However, my guess is that the inet address that you have there shows the same IP address in hex notation each time.

Next would be a shared session configuration. Not the normal "shared session key" that you'd see with ssh or similar, but something along the lines of phoning a tech support number and getting a different operator each time. The difference is, you'd still expect to be talking to "tech support" - here, you have a 4 different processes (plus one duplicate) listening on the same number. What I'd normally expect to see in that case would be a system designed for multiple CPUs where it'd look like you have one incoming port, but actually have multiple processes listening on the back end.

My main guess here is that unix_vb is like a manager process which would farm the connection out to an appropriate process to deal with it. Without any knowledge of the application, my guess is that it'll fall apart after you kill off unix_vb, since it doesn't have anything to redirect incoming requests to the appropriate application.

Does seem like a wierd way to program it though - is it designed for tight security through firewalls?

[Sunil Surve]

hello,

actually the processes shown here are all mutually exclusive. The unix_vb process creates the socket and uses it. But none of the other processes use it. What i have observed is that for all the processes the login is the same. Is it like a socket created by a particular process for a paticular user is also visible to all the other processes of that same login even if the other processes dont use it...?

thnx & rgds,