Listen port is still open after the process was killed

[郭尚中_1]

We have a process which use TCP port xxxx as the listener port of service. Now we killed the process for some reason, but the port xxxx is still open when we monitor it using netstat command and we can not restart our daemon because of the opening port. We have to reboot our Tru64 unix. Does anyone has idea this problem. We don't want to reboot unix each time.
Version: Tru64 Unix V5.1A with PK6

[Michael Schulte zur Sur · Accepted solution]

Hi,

can you post the netstat output?

greetings,

Michael

[郭尚中_1]

Thanks for your messages, I will post it here when this happen again.

[Ralf Puchner]

It seems an application programming problem. Sockets are not automatically closed it must be done programmatically. So please implement an kill-signal handler within your application.

[郭尚中_1]

Thanks for your messages, the application is apache, one important messages is we are using truss to trace the application during that times. I'm wondering if it can lead to the problem.

[Venkatesh BL]

Any other process using the same port still?. I am not sure how you can find this out...

[Don Ritchey]

Obtain the freeware tool 'lsof' or 'List Open Files' from the Purdue University archives:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof

Build and install the tool, and run the command with the options:
lsof -i :xxxx
where xxxx is the port your program is using, and it will show any programs holding the port open. If you were using a debugger to look at the program, it may have held the port open after you were done looking at the program and did not exit from the debugger program.

Best wishes for solving the problem,

Don

[Hamel_2]

Hello,

We had similar issue with envmond daemon, which can't start at boot time because its ports were used temporary by another process for outgoing connection.
To avoid listening/outgoing collision ports, we used 2 inet_sys parameters :
ipport_userreserved=60000
ipport_userreserved_min=32768
By default, Tru64 use port beginning at 1024 for outgoing connection.

[Florian Heigl (new acc)]

next time please look at the results of the following:

netstat -na | grep | grep WAIT

- I'd guess the port shows being in state FIN_WAIT_2.

I haven't yet found documentation on how this timeout is influenced on Tru64 [sysctl, ndd, whatever] and don't have access to my test system in the next time, so You might want to ask HP :)

(As a reference On HP-UX is goes by the name of 'tcp_fin_wait_2_timeout')

[Florian Heigl (new acc)]

See the following thread for Tru64 instructions:

http://groups.google.de/group/comp.unix.admin/browse_thread/thread/722503930360f000/b9ab87f6517d69f8?lnk=st&q=tru64+fin_wait&rnum=4&hl=de#b9ab87f6517d69f8