NFS Services Administrator's Guide (5900-2134, March 2012)

<other tracing>
...
<other tracing>
UNMOUNT REPLY: <status>=unmount status
The unmount status in the unmount reply contains 0 if the unmount is successful; it has a
non-zero value when the unmount is not successful.
The following is an example of a typical unmount trace event:
May 13 18:46:27 t1 UNMOUNT REQUEST: Tue May 13 18:46:27 2003
May 13 18:46:27 t1 dev=44000004 rdev=0 direct
May 13 18:46:27 t1 ping: hpnfs127 request vers=3 min=2
May 13 18:46:27 t1 pingnfs OK: nfs version=3
May 13 18:46:27 t1 nfsunmount: umount /n2ktmp_8264/nfs127/tmp
May 13 18:46:27 t1 Port numbers are 937, 937
May 13 18:46:27 t1 Port match
May 13 18:46:27 t1 nfsunmount: umount /n2ktmp_8264/nfs127/tmp OK
May 13 18:46:27 t1 unmount /n2ktmp_8264/nfs127/tmp OK
May 13 18:46:27 t1 UNMOUNT REPLY: status=0
AutoFS Configuration in Build Environment
AutoFS automatically mounts and unmounts file systems after a period of inactivity. When the build
activity is taking place, the linker caches the object file's device id. If the build activity takes more
time than AutoFS inactivity time, AutoFS unmounts and remounts the NFS file system. This unmount
and remount of the NFS filesystem results in a change to the NFS Filesystem device ID. This can
result in build failure when the linker re-validates the cached NFS Filesystem device ID.
The workaround for this issue is to increase the AutoFS unmount time. Refer to the “AutoFS
Configuration Changes” (page 56) section for information on changing the AutoFS unmount time.
Another workaround is to force the filesystem to remain busy by opening a temporary file, so that
AutoFS cannot unmount it.
Troubleshooting AutoFS 77