netstat hangs

[Steven Whatley]

Hi all,

We are running Tru64 v5.1A on three ES40s. We also have N class and L class HP-UX 11.00 systems. We recently installed a an internal gigabit network (alt0) in addition to the our existing 100baseT LAN (tu0). The gigabit network handles our NFS traffic. alt0 is assigned an 192.168.x.y IP address.

Ever since we added the gigibit network, netstat hangs or takes a long time (20 minutes) to time out. netstat -ai hangs. Also, this is causing a problem with syscheck hanging on one of our sysstesm where netstat won't run at all (just hangs with no output). Does anyone have any idea of why netstat is haning?

We also have fibre channel cards in the systems and these have not caused any netstat problems.

Any info will be appreciated.

Thanks,
Steven

[Ralf Puchner]

try netstat -rn and netstat -r, does it hang with -n? If not it seems a host resolution problem.

Another question is if you have tuned the machine for gigabit usage and if the adapter is plugged into the right slot/an idle bus.

Btw. fibrechannel is different to network, so why should a non network device interact with a network command?

[Matt Palmer_2]

Hi,

have you checked in /etc/resolv.conf or HP-UX equivalent. It may be that you DNS is incorrectly set or down.

this happened to me before on T64 and this was where the problem was.

[Ralf Puchner]

Matt,

to check the naming resolution was my intension with the test of "netstat -r".
resolv.conf is the config file to specify which naming resolution subsystem will be used and is starter after netstat -r worked.

[Lewis_11]

Hello all,

This thread seems to have gone to sleep. That's a shame, as we too have a problem with netstat hanging under Tru64 v5.1A.

The server concerned does have an internal gigabit network (alt0), but I do not know if this is relevant.

We find that after rebooting the system the problem does not occur for several days, but then something happens (resource problem?), after which netstat hangs every time. No errors are logged anywhere, and the only solution we have found is to reboot. It does not appear to be a name resolution problem, as netstat hangs just the same when run with the -n option.

I wondered if Steven had made any progress on this one. If so, I'd be delighted to have any news.

Thanks, and best wishes,
David

[Lewis_11 · Accepted solution]

I've found a solution to my problem :

* look for running /sbin/kloadsrv process
* kill it
* restart /sbin/kloadsrv

Best regards,
David

[Steven Whatley]

Yes, restarting kloadsrv fixes the problem but only temporarily. As the message header count goes oup it will hit the limit. Ours iis set to 40. We were having to restart koadserv at least once a week. Users could not run Netscape because it calls netstat.

You can check the current count by running following command as root:

# dbx -k /vmunix
dbx> p cur_msghdrs

We never found out what was causing the message count to go up. Last month we upgraded to Tru64 5.1B and the problem seems to have gone way.

Hope this helps,
Steven

[Domaigne]

All,

We were faced to the same problem. From my investigations, one reason for netstat to hang is when a message queue becomes full. If, for some reason (like receiving process missing), a sending process overflows a message queue, then it causes netstat to hang.

For more information, please read my posts:
- on Tru64-UNIX-Managers list: "about netstat hangs", dated from 2004-05-05.
- on comp.unix.tru64: "netstat issue on Tru64. Kernel bug?" dated from 2004-06-08.

IMHO, this is a kernel bug. Opinions from Tru64 experts would be greatly appreciated.


Cheers,
Loic.

[Ralf Puchner]

If it is a kernel bug, why not opening a call within the HP support center? HP can not work on the problem without call...