HP-UX11.0 sockets : strange behaviour.

[bernard bedetti]

Our developers have programmed a client/server Unix application based on Socket, and for testing, they launch and stop this application many times per day.

After a while, the application no longer works without error messages and a simple reboot of the machines solves the problem !

Does that mean some communication system tables are not correctly cleaned (could be) ?

Thanks in advance if somebody has an idea.

The platform is composed of a Cluster (2 * HP9000/L2000 with MC/ServiceGuard) and a set of HP9000/C3000 and 360 machines.

[Alexander Graf_2]

Hi,

what kind of error messages?
After how many times does this behavior occur?

Alex

[U.SivaKumar_2]

Hi,

The network application under discussion may be overflowing the kernel paramters line like maxfiles , nfiles etc.

Check for any error messages in /var/adm/syslog/syslog.log after start and stop of this application.

Try to get recommendations from the same developers to tune the kernel.

regards,

U.SivaKumar

[Steven Gillard_2]

If the application isn't producing useful error messages when it fails, try running tusc on it to get a system call trace. That will reveal the system call that is failing and the error.

You can get tusc here:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/tusc-7.5/

Feel free to post the output if you have trouble interpreting it.

Regards,
Steve

[Ron Kinner]

I suspect they are not closing their connections correctly and leaving a ton of connections in FIN_WAIT_II or LAST_ACK. Next time it breaks do
netstat -an > junk
and look at the output in junk to see if you have a lot of stuck connections.

Ron

[A. Clay Stephenson]

This is almost certainly the result of poor programming practices. A very common source of this is not properly closing sockets especially when the process receives a signal (e.g. user pressed Ctrl-C). If the application is generating error messages the it should be absolutely clear what is wrong especially if you can also get them to output errno in conjunction with the error message.

[rick jones]

In addition to making sure that connections are closed properly - like making sure stuff gets closed after forks and such, the application must also remember to use setsockopt() to set SO_REUSEADDR before trying to bind to its well-known port number. This will allow the server application to be restarted while there are still old connections in TIME_WIAT or FIN_WAIT_*

And make sure that the application is written to provide useful error messages - inlcuding the value of errno. And then include those messages in the next report :)