Strange networking problem

[Bengt Nilsson_2]

I have a problem with networking on a DS10 running tru64v5.1B after some hardware troubleshooting and repair.
I found some memory problems, and the banks are now replaced. The hw configuration is now same as the working one before the problems started. Most probably something changed in the sw config during this work, and I lost control.
NFS is not working reliably, I have lots of collissions, file transfer hangs, etc.
/var/adm/syslog.dated/current/daemaon.log says repeatedly
Oct 13 09:25:45 mc2-p007 mountd[9717]: startup
Oct 13 09:25:45 mc2-p007 mountd[9718]: file write lock on /var/run/mountd.pid failed (line 1077): Permission denied
Oct 13 09:25:45 mc2-p007 nfsd:[9722]: Can't bind UDP addr: Address already in use
Oct 13 09:25:45 mc2-p007 statd[9725]: rpc.statd bind (udp): Address already in use
Oct 13 09:25:45 mc2-p007 lockd[9729]: rpc.lockd bind (tcp) Address already in use

Where should I start looking?
How can I check what address is already in use? And why?

And finally, I __did__ try googling on this one before asking here. No suitable results.

BN

[Rob Leadbeater]

Hi,

> NFS is not working reliably, I have lots of collissions, file transfer hangs

I would start by checking that the speed/duplex of the NIC in the server is the same as it was before - or that it matches the switch into which it is connected.

That's one of the usual suspects for strange network issues.

Regards,

Rob

[Bengt Nilsson_2]

That was actually the first thing I checked, it is >>> FastFD.
It is connected to a HP Procure 2324 unmanaged switch, which I assue would adapt accordingly, at least it did so before.

When I use sysman and check "View NFS daemon status", they (Lockd,Statd,NFS i/o, NFS, Mount) are always stopped, even right after I "Start/Restart NFS daemons", reporting "NFS daemons restarted successfully"

[Rob Leadbeater · Accepted solution]

If it's an unmanaged switch, I'd be tempted to set the server to Auto Negotiate...

[Bengt Nilsson_2]

Ok, i'll try that instead.

[Bengt Nilsson_2]

Ok, I give in.
I was positively abolutely convinced that FastFD was correct, I've had this setting for years and it worked fine. Until last week.
After changing to Auto-Negotiate everything started working as it should. Actually, I had to change this setting on the clients too.
BUT - why is sysman reporting that the NFS and lock daemons are stopped? When they are not(?)?

BN

[Steven Schweda]

> [...] file write lock on
> /var/run/mountd.pid failed (line 1077):
> Permission denied

> [...] Address already in use

Are you trying to run multiple copies of
these daemons? (It appears so to me.)

> BUT - why is sysman reporting [...]

If sysman is confused, I'd avoid using sysman
for a while. Does "ps" find these things?
Can you kill ("kill") them all manually? (And
start them all again using the usual "rc"
script?)

[Bengt Nilsson_2]

Yes, I begin to distrust sysman in this case.
However, I have seen it report correctly on another v5.1B system.

mc2-p007# ps -ef | grep rpc
root 8979 1 0.0 20:40:52 ?? 0:00.01 /usr/sbin/rpc.statd
root 8982 1 0.0 20:40:52 ?? 0:00.01 /usr/sbin/rpc.lockd
root 9022 8926 0.0 20:42:35 pts/1 0:00.00 grep rpc
mc2-p007# ps -ef | grep nfs
root 8973 1 0.0 20:40:52 ?? 0:00.01 /usr/sbin/nfsd -t32 -u32
root 8976 1 0.0 20:40:52 ?? 0:00.00 /usr/sbin/nfsiod 32
root 9024 8926 0.0 20:42:42 pts/1 0:00.00 grep nfs


so something is running here.
init.d/nfs starts and stops without errors.

So I should just ignore sysman and be happy?

[Bengt Nilsson_2]

>> [...] file write lock on
>>> /var/run/mountd.pid failed (line 1077):
>>> Permission denied

>>> [...] Address already in use

>>Are you trying to run multiple copies of
>>these daemons? (It appears so to me.)

I agree, it seems so. But if I do, it would be the mistake of sysman. I just press the "Restart NFS" button.

[Steven Schweda]

> [...] I just press the "Restart NFS" button.

I don't know what sysman does when you do
that. Perhaps it looks at a ".pid" file
which has bad data in it, and then tries to
kill the wrong process. That's why I
suggested using "ps", and killing everything
manually. A fresh start might straighten
things out.

"reboot" might help, too, of course.