Diagnosis Guide

Actions

Action 1 - Check the /etc/security/passwd file

If a user is having problems logging in to nodes in the SP System, check the login and rlogin attributes for the user in the /etc/security/passwd file on the SP node.

Action 2 - Check Login Control

Check the Login Control facility to see whether the user's access to the node has been blocked.

The System Administrator should verify that the user is allowed access. The System Administrator may have blocked interactive access so that parallel jobs could run on a node.

Action 3 - Verify that the automount daemon is running

On AIX 4.3.1 and later systems, the AutoFS function replaces the automount function of AIX 4.3.0 and earlier systems. All automount functions are compatible with AutoFS. With AutoFS, file systems are mounted directly to the target directory instead of using an intermediate mount point and symbolic links.

Review the commands in the following table and issue the ones that are appropriate for diagnosing the problem.

Table 70. Automounter Related Commands

Command	Comments
ps -ef \| grep automount	Verifies that the automount daemon is running on the system on which you are having problems accessing directories.
lssrc -g autofs	For AIX 4.3.1 and later systems, the automounter is controlled by the System Resource Controller (SRC). This command indicates whether the automountd daemon is active or not.
mount	For AIX 4.3.0 and earlier systems, provides the process id of the automount daemon if it is running, the names of the file systems controlled by the automount daemon, and the active mounts under the /tmp_mnt directory. For AIX 4.3.1 and later systems, provides the names of the file systems controlled by the automounter daemon and lists any currently active mounts under the /tmp_mnt directory.
view /var/adm/SPlogs/auto/auto.log	Contains error messages generated by PSSP.
view /var/adm/SPlogs/SPdaemon.log	Contains error messages generated by the automount daemon.
splstdata -e \| grep amd_config	Informs whether SP automounter has been configured.
splstdata -e \| grep usermgmt_config	Informs whether SP user management support has been configured.
splstdata -e \| grep filecoll_config	Informs whether SP file collections have been configured.
view /etc/auto.master	Lists the file systems to be controlled by automount and their associated map files.
ls -l /etc/auto/maps	Lists of map files and whether they are readable. Specifically, the existence of auto.u map file.
view /etc/auto/maps/auto.u	Lists the user map entries for the /u file system.
ls -l /etc/auto/cust	Lists customization files and whether they are executable.
view /var/sysman/sup/lists/user.admin	Lists automounter files that are distributed through file collections.

It may be that the automounter daemon is not running. It is also possible that automount is running but that there is another problem. For AIX 4.3.0 or earlier systems, issue:

ps -ef | grep automount

For AIX 4.3.1 or later systems, issue:

lssrc -g autofs

1. Automount Is not running

If issuing the previous command did not show that the automount process was running, issue:

mount

to see if any automount points are still in use. If you see an entry similar to the following one, there is still an active automount mount point. This is for AIX 4.3.0 and earlier systems:

luna.pok.ibm.com (pid23450@/u) /u afs Nov 07 15:41 ro,noacl,ignore

For AIX 4.3.1 and later systems, the output is:

/etc/auto/maps/auto.u /u autofs Aug 07 11:16 ignore

Attempt to unmount the file system by issuing:

unmount /u

If the file system is busy, issue the following command to determine the processes that are accessing the file system. Stop all of these processes and attempt to unmount the file system again.

fuser /u

If the mount command does not show any active mounts for automount, issue the following command to start the automounter:

/etc/auto/startauto

Proceed as follows:

If startauto succeeds
If this command succeeds, issue the previous ps or lssrc command again to verify that the automount daemon is actually running. If so, verify that the user directories can be accessed or continue with 2. Automounter is running, but the user cannot access user files.
Note that the automount daemon should be started automatically during boot. Check to see if your SP system is configured for automounter support by issuing:
```
splstdata -e | grep amd_config
```
If the result is true, you have automounter support configured for the SP system in your Site Environment options.
If the startauto command was successful but the automount daemon is still not running, check to see if the SP automounter function has been replaced by issuing:
```
ls -l /etc/auto/cust
```
If the result of this command contains an entry similar to:
```
-rwx ----- 1 root system 0 Nov 12 13:20 startauto.cust
```
the SP system function to start the automounter has been replaced. View this file to determine which automounter was started and follow local procedures for diagnosing problems for that automounter.
If the result of the ls command does not show any executable user customization script, check both the automounter log file /var/adm/SPlogs/auto/auto.log and the daemon log file /var/adm/SPlogs/SPdaemon.log for error messages. Find the recorded error messages in PSSP: Messages Reference or in the AIX error message documentation and follow the recommended actions.
If startauto fails
If the startauto command fails, find the reported error messages in PSSP: Messages Reference and follow the recommended actions. Check the automounter log file /var/adm/SPlogs/auto/auto.log for additional messages. Also, check the daemon log file /var/adm/SPlogs/SPdaemon.log for messages that may have been written by the automounter daemon itself.
If no error messages were recorded, the failure may be due to problems with the automount map files, master map file, or the /u directory. Check the following:
- Verify that all entries in the automount master map file /etc/auto.master are correct and follow the format specified in the AIX publication System Management Guide: Communications and Networks. If there are no entries in this file, the automount daemon invocation will fail.
- Verify that each map file the master map references is correct, and follows the format specified in the same AIX publication.
- Verify that each file system listed in the master map file is a local directory and is not a symbolic link to another directory. PSSP: Administration Guide contains a chapter on managing the Automount that contains useful information for understanding your SP automounter installation.

2. Automounter is running, but the user cannot access user files

For an AIX 4.3.0 or earlier system, if the result of issuing the ps -ef | grep automount command is similar to:

 root 21430    1   0  10:37:41    0:00 /usr/sbin/automount
 /etc/auto.master  -m -D HOST=k22n11

then the automount daemon is running.

For an AIX 4.3.1 or later system, if the result of issuing the lssrc -g autofs command is similar to:

Subsystem       Group      PID     Status
automountd      autofs     12126   active

then the automount daemon is running.

The problem may be that automount is waiting for a response from an NFS server that is not responding, or there is a problem with a map file.

Check the /var/adm/SPlogs/SPdaemon.log for information relating to NFS servers not responding. If a user's files are mounted with NFS and the server is not responding, then automount may hang on the NFS mount request. Correct this NFS failure before continuing. After you resolve the NFS failure, you can restart the automount daemon.

If the problem does not appear to be related to an NFS failure, you will need to check your automount maps. Look at the /ect/auto/maps/auto.u map file to see if an entry for the user exists in this file. If the user's name is test, and the command cd /u/test results in:

ksh:  /u/test:   not found

you can look at the auto.u map to see if there is an entry defined for the user by issuing:

grep test /etc/auto/maps/auto.u

The result may indicate that there is no entry for this user in the automounter map. This can happen if the user was recently added, and the maps have not been distributed in the file collections. To check if the file gets updated with the new map copied from the control workstation, issue the following command on the node experiencing the problems:

supper update -v user.admin

Note that the automount maps are automatically distributed to the nodes each hour by command in the cron. You can look at these commands with crontab -l.

After you updated the auto.u map with the version that contains the user information, reread the auto.u map by issuing:

grep test /etc/auto/maps/auto.u

If the result appears as follows:

test   luna:/home/luna:&

issue the following:

cd /u/test

If the cd command does not work, there may not be a route to the hostname specified in the host field of the user's automount map entry. This can happen on file servers where there are multiple interfaces, and the routing has not been defined for all of the interfaces, from the systems attempting to access the server. You can verify this by attempting to ping the server specified.

Another possible problem is that the server is exporting the file system to an interface that is not the interface from which the client is requesting the mount. This problem can be found by attempting to mount the file system manually on the system where the failure is occurring. For the map in the previous example, you could issue:

mount luna:/home/luna /mnt

to mount the file system on /mnt. Listing the contents would show the user's files. If the map file information is incorrect, use the spchuser command from the control workstation to update the map file entry for the user. For example, if the test user's home directory moves from luna to starship, you would issue:

spchuser home=starship:/home/starship/test test

This will update the automount map file. You must then wait for as long as five minutes with no access attempts to the /u/test directory. This will allow the automount daemon to time out any old access attempts to the previously mounted luna:/home/luna exported file system. Do not attempt to force the unmount by manually issuing the unmount command on the previously mounted file system. This will put the automounter daemon in an inconsistent state and you will need to stop and restart the daemon to recover access to the /u/test directory.

Stopping and restarting automount

If you have determined that you need to stop and restart the automount daemon, the cleanest and safest way is to reboot the system. However, this may not be desired due to other processes currently running on the system. If you cannot reboot the system, follow these steps:

Determine whether any users are already working on the directories mounted by the autmountd daemon. Issue: mount
If automounter is controlling any file systems, you will see an entry similar to:
```
/etc/auto/maps/auto.u /u  autofs Aug 07 11:16 ignore
```
Also, if a user is working in a directory mounted by the atumounter, you will see an entry similar to:
```
luna.pok.ibm.com luna.pok.ibm.com:/home/luna/test /u/test nfs Aug 10 10:37
```
You can request the user to either logoff, or cd out of their home directory so that the directory will no longer be in use. If any directory managed by the automounter is accessed while the daemon is stopped, the file system may hang.
Stop the automountd daemon with this command:
```
stopsrc -g autofs
```
Note that it is important that you DO NOT stop the daemon with the kill -kill or kill -9 command. This may cause file system hangs and force you to reboot your system to recover those file systems.
Restart the automounter
```
/etc/auto/startauto
```
You can verify that the daemon is running by issuing the previous lssrc command.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]