CDE login on mixed network

[Stuart Lloyd_2]

First, let me say that I have a Frankenstein network. Our NFS server is an HP 10.20 named "H". Our NIS/DNS/YP server is a SunOS 5.5.1 named "E".

About 2 months ago all network users started experiencing login issues. We have HP 10.20 and 11, AIX 4.2.1 and 4.3.4, and almost every flavor of Solaris. Whether loggin in to the machines through Exceed or sitting in front of the machine the logins are taking 10-15 minutes if they work at all.

H has everyone's home directory which is mounted to every Unix box in the office. E has the passwd file which references each users home directory.

The only user that doesn't have an issue is root... for obvious reasons. If the user is local it's no issue but if it's a network user we bog down.

Any clues?

[curt larson_1 · Accepted solution]

take a look at how statd and lockd are doing.

Check whether the NFS server is up and operating correctly. See If You Receive an NFS 'Server Not Responding' Message.

If the server is down, wait until it comes back up, or, if the directory was mounted with the intr mount option (the default), you can interrupt the NFS mount, usually with CTRL-C.
If the program uses file locking, issue the following commands (on either the client or the server) to make sure rpc.statd and rpc.lockd are available and responding to RPC requests:
/usr/bin/rpcinfo -u servername status
/usr/bin/rpcinfo -u servername llockmgr
/usr/bin/rpcinfo -u servername nlockmgr
/usr/bin/rpcinfo -u clientname status
/usr/bin/rpcinfo -u clientname llockmgr
/usr/bin/rpcinfo -u clientname nlockmgr
If any of these commands returns RPC_TIMED_OUT, the rpc.statd or rpc.lockd process may be hung. Follow these steps to restart rpc.statd and rpc.lockd:


Issue the following commands, on both the NFS client and the NFS server, to kill rpc.statd and rpc.lockd (PID is a process ID returned by the ps command):
/usr/bin/ps -ef | /usr/bin/grep rpc.statd
/usr/bin/kill PID
/usr/bin/ps -ef | /usr/bin/grep rpc.lockd
/usr/bin/kill PID

Issue the following commands, on both the client and the server, to remove the contents of the sm and sm.bak directories:
/usr/bin/rm -r /etc/sm
/usr/bin/rm -r /etc/sm.bak

Issue the following commands to restart rpc.statd and rpc.lockd on both the client and the server:
/usr/sbin/rpc.statd
/usr/sbin/rpc.lockd

--------------------------------------------------------------------------------
Always start rpc.statd before starting rpc.lockd.

--------------------------------------------------------------------------------


Issue the following commands to verify that rpc.statd, rpc.lockd, and nfsd are all running and responding to RPC requests:
/usr/bin/rpcinfo -u servername status
/usr/bin/rpcinfo -u servername llockmgr
/usr/bin/rpcinfo -u servername nlockmgr
/usr/bin/rpcinfo -u servername nfs
/usr/bin/rpcinfo -u clientname status
/usr/bin/rpcinfo -u clientname llockmgr
/usr/bin/rpcinfo -u clientname nlockmgr
/usr/bin/rpcinfo -u clientname nfs

Wait two minutes before retrying the mount that caused the program to hang.

If the problem persists, restart rpc.statd and rpc.lockd, and turn on tracing.

To start detailed logging of rpc.statd and rpc.lockd while they are running, issue the following commands (PID is a process ID returned by the ps command):

/usr/bin/ps -ef | /usr/bin/grep rpc.statd
/usr/bin/kill -SIGUSR2 PID
/usr/bin/ps -ef | /usr/bin/grep rpc.lockd
/usr/bin/kill -SIGUSR2 PID
The SIGUSR2 signal sets the logging to level 3 (the most detailed level).
The logging for rpc.statd is appended to the file /var/adm/rpc.statd.log. The logging for rpc.lockd is appended to the file /var/adm/rpc.lockd.log.

To stop detailed logging of rpc.statd and rpc.lockd, issue the same commands listed above to send the SIGUSR2 signal to the processes. The SIGUSR2 signal is a toggle that turns logging on or off, depending on its current state.

For more information, type man 1M statd or man 1M lockd at the HP-UX prompt.

[curt larson_1]

usually what is happening is the shell is having a problem getting a file lock on it's history file, (usually ~/.sh_history). while the above will help you identify the issue. your going to have to check and make sure you have the lastest patches (arpa,nfs,rpc, and other related networking patching).

And 10.20 is obsolete, might be a good oppourtunity to upgrade to 11i.

[Mark Ellzey]

Stuart,

One other thing that may be causing the login to hang is name resolution. Check your /etc/resolv.conf and /etc/nsswitch.conf files.

You can check the name resolution on a host by using the nslookup(1) command. If it hangs, then check that your DNS server is up and has the correct IP addresses for the host you are looking up. Check for an IP conflict between /etc/hosts, NIS and DNS.

Regards,
Mark

[Judy Traynor]

You may have a tooltalk problem, and to resolve, you will need to stop rpc.ttdbserver
Comment out that line in /etc/inetd.conf -
ps -ef | grep rpc.ttdb
and kill the pid

reread the inetd.conf via the command
inetd -c

Find all the Directories named TT_DB on your file/nfs server and delete them

find . -name TT_DB -exec rm -r {} \;
(be careful with that one.. I recommend you do it manually.)


Once they are all deleted, uncomment /etc/inetd.conf
and reread the file

inetd -c


Before you do all this, run top, and see if rpc.ttdbserver is your top process.

Good luck