Ignite-UX Frequently Asked Questions

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 sides. 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 will contact 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 wiped
out. In this case, if the reinstalled client tries to re-contact 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 a several ways to avoid and/or fix the problem if it
happens:
- If you are using bootsys to install clients, use the -s option to
allow the client to shutdown normally and thus inform servers that
it is going down.
- 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 flush its cache. If more than one server is involved
you may end up doing 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 server's name. 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 could 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
"
===============================================================================
1.7
Q: Why do the iux_postconfig scripts associated with EMS KRM sometimes
fail?
A: On some HP-UX 11.x clients you might see the following errors when
recovering a client from a make_net_recovery or make_tape_recovery
tape, or a make_net_recovery image:
Executing:
"/var/adm/sw/products/EMS-KRMonitor/KRMON-RUN/iux_postconfig".
ERROR: Cannot install a dlkm driver.
ERROR: Cannot configure a dlkm driver.
ERROR: The script:
"/var/adm/sw/products/EMS-KRMonitor/KRMON-RUN/iux_postconfig"
failed, exit code was 1.
The reason for this is when the recovery archive was created, the
kernel the client was running was not created correctly (the DLKM
information was out of sync). You should always use kmupdate to move
a new kernel into place after creating it with mk_kernel, this will
move the DLKM information into place when the new vmunix is moved
into place at the next shutdown.
To solve this problem, create a kernel in the way described above
then recreate the recovery tape or network recovery archive. You
should not see this message the next time you use the new tape or
network recovery archive (the old tape or network recovery archive
will always show this problem).