Ignite-UX (IUX) Document for Frequently Asked Questions (FAQ) (762793-001, March 2014) (Edition: 3)

subnet that does not have a route to the IP address specified by the server, then it will not be able
to contact the server after it boots.
The workaround for this problem are as follows:
• Manually correct the IP address of the server on the networking screen that appears on the
client console when you boot the client.
• Use a boot helper on each subnet. When using a boot helper, the IP address of the server
can be specified correctly on each helper system. For more information about complex network
solutions, see Ignite-UX Administration Guide at www.hp.com/go/ignite-ux-docs.
Why do some applications and shells hang over NFS after igniting?
The reason for the hang is most likely due to a problem with the NFS file locking daemons
rpc.statd and rpc.lockd, caused by the action of reinstalling the client.
Many applications use file locking and can hang in this situation. Most common is the user home
directories that are NFS mounted. In which case, sh and ksh attempt to lock the .sh_history
file and hang before giving you a prompt.
When a client is running and has an active NFS mount with a server in which files have been
previously locked, both the client and server cache information about each other. Part of the
information that is cached is what the RPC port number uses to contact the rpc.lockd daemon
on the server and client.
This RPC port information is cached in memory of the running rpc.statd/rpc.lockd process
on both the server and client side. The rpc.statd process keeps a file in the directory /var/
statmon/sm for each client that it knows to contact in the event that the client reboots (or
rpc.statd/rpc.lockd restarts). During a normal reboot or crash, rpc.statd a message is
sent to each client in /var/statmon/sm and inform them to flush their caches regarding this
client.
When you reinstall a client, the /var/statmon/sm directory is cleared. In this case, if the
reinstalled client tries to recontact a server that has cached information, the server will try to
communicate over an old RPC port. The communication will fail for rpc.lockd and any file
locking done by an application over that NFS mount will hang.
There are several ways to avoid or fix the problem if it occurs:
• If you experience a hang, you can reboot the client, or kill/restart rpc.lockd and rpc.statd
on the client. At the point of the hang, the /var/statmon/sm directory will contain the name
of the server, and thus rebooting or restarting the daemons will tell the server to clear its cache.
If more than one server is involved you might have to do this multiple times until all servers
are notified.
• As part of the installation, create a file for each server in /var/statmon/sm, which contains
the name of the server. This will cause the first boot to generate a crash recovery notification
message to each server, causing them to purge the stale port information. The following is an
example post_config_cmd stanza that can be placed in your /var/opt/ignite/
config.local file:
post_config_cmd += "
mkdir -p /var/statmon/sm
for server in sys1 sys2 sys3
do
echo $server > /var/statmon/sm/$server
chmod 0200 /var/statmon/sm/$server
done
"
10 Known problems