Chapter 8. Using the File Alteration Monitor
Prev |  | Next

## Chapter 8. Using the File Alteration Monitor

The File Alteration Monitor (`fam`) is a daemon that monitors files and directories. Application writers can include certain function calls in their applications to let `fam` know that they want to be informed of changes to whichever files and/or directories they specify. For example, `mailbox(1)` uses `fam` to know when to indicate the arrival of new mail. The `fam` daemon runs only when applications using it are running; it exits after all programs using it have stopped. For additional information about `fam` usage, see the fam(1M) and `fam(3X)` man pages.

## Configuration File

Beginning with the IRIX 6.5.8 release, you can use a configuration file, in addition to the command-line options, to control `fam` behavior. By default, this file is called`/etc/fam.conf`; you can enter the -c command-line option to specify an alternate file.

Configuration lines are in the format `option=value` as shown in Example 8-1. Lines beginning with # or ! are ignored. The daemon recognizes the `insecure_compatibility`, `untrusted_user`, `local_only`, and `xtab_verification` options illustrated in the default file. For a description of these options, see the `fam(1M)` man page.

Example 8-1. Default `fam.conf` File

    #  fam.conf
    #
    # For more information on the configuration options below, see the
    # fam(1M) man page.

    #
    # insecure_compatibility disables authentication.  This causes
    # untrusted_user to be ignored, because the UID presented by every
    # client connection will be believed.
    #
    # The -C command-line argument overrides this option.
    #
    insecure_compatibility = false

    #
    # untrusted_user is the user which will be used for unauthenticated
    # clients.  If a file can't be stat'ed by this user, those clients
    # won't be able to fam it.  The value can be a user name or a
    # numeric UID.
    #
    untrusted_user = nobody
    #

    #
    # local_only makes fam ignore requests from remote clients & remote
    # fams. Note that this is ignored if fam is started by inetd.
    #
    # The -L command-line argument overrides this option.
    #
    local_only = false

    #
    # xtab_verification makes fam check the list of exported filesystems
    # to verify that requests from remote hosts fall on filesystems
    # which are exported to the hosts.
    #
    xtab_verification = true

## Basic `fam` Troubleshooting

Sometimes, when attempting to start up an application that uses `fam`, an error message is displayed:

    Cannot connect with File Alteration Monitor (fam)

There are several reasons why this message appears. This section describes some of the common ways to troubleshoot the problem.

If you see one of the following two messages on your screen, follow the steps in Procedure 8-1:

    Can't connect to fam
    Cannot connect with File Alteration Monitor (fam)

Procedure 8-1. Troubleshooting `fam`

1. Check the `/var/adm/SYSLOG` file (the system log) for useful messages. For instructions on using the sysmon tool, see “sysmon, the System Log Viewer” in Chapter 2.

2. See if `fam` is running with the following `ps` command:

       ps -ef | grep fam

   If `fam` is running, verify that it was started by `inetd`. The parent PID (PPID) listed for the `fam` process should match the PID returned by the following `ps` command:

       ps -ef | grep inetd

   If `fam` is not running, that does not necessarily indicate a problem. The `fam` daemon is normally started by `inetd` when an application needs it, and `fam` only runs as long as it is being used by one or more client applications.

3. Verify that `fam` is listed in the `/etc/inetd.conf` file.

   1. Run the following `grep` command:

      `grep fam /etc/inetd.conf`

   2. Look for output similar to the following:

      `sgi_fam/1-2 stream rpc/tcp wait root ?/usr/etc/fam fam`

      The `fam` daemon is `/user/etc/fam`.

   3. If that line is not present, add it, and make `inetd` reread the file by running the following `killall` command:

      `killall -HUP inetd`

4. Verify that the `fam` daemon is present and executable by `root`. That is, the `/usr/etc/fam` file`.` If the file is not found, you must reinstall the `eoe.sw.base` subsystem.

5. Verify that fam is listed in the `/etc/rpc` file:

   1. Run the following `grep` command:

      `grep fam /etc/rpc`

   2. Look for output similar to the following:

      `sgi_fam 391002`

6. Verify that `inetd` is running with the following `ps` command:

       ps -ef | grep inetd

   1. Look for a response similar to the following:

      `root 214 1 0 Oct 24 ? 0:01 /usr/etc/inetd`

   2. If the following message is displayed, it is a sign that the network is not active.

      `portmapper failure`

      For information on network administration, see IRIX Admin: Networking and Mail .

7. Verify that `fam` is registered with `portmapper` by using the `rpcinfo` command:

       rpcinfo -p | grep fam

   When `inetd` reads the `/etc/inetd.conf` file, it registers the RPC services it finds (such as `fam`) with the `portmapper` so that client applications can connect to specific ports for the services they need.

   1. Look for output similar to the following:

          391002    1   tcp   1033  sgi_fam
          391002    2   tcp   1033  sgi_fam

      If the `rpcinfo` command does not produce any output, then `fam` is not registered with the `portmapper`. If you have performed the previous steps (including `killall -HUP inetd`), it is possible that the `portmapper` is not running.

8. Verify that `inetd` or `fam` is indeed listening on the registered ports.

   In the sample output above, the port is 1033. To find out which processes are listening on it, run the `fuser` command:

       fuser 1033/tcp

   1. If you see the following output, processes 223 and 627 have port 1033 open.

          1033/tcp:      223o     627o

      Use the `ps` command to determine whether those processes are `inetd` and `fam`.

   2. On the other hand, if the `fuser` output is more like the following, then the `portmapper` information is confused and the network services probably needs to be restarted.

          1033/tcp: fuser: No such file or directory

9. If everything else looks like `fam` should be receiving connections, try turning on `fam` debugging by adding the `-d` option to the `fam` entry in `/etc/inetd.conf`. The edited line should be similar to the following:

       sgi_fam/1-2   stream   rpc/tcp   wait   root ?/usr/etc/fam   fam -d

   1. After editing the `inetd.conf` file, make `inetd` reread the file by running the `killall` command:

          killall -HUP inetd

   2. If `fam` is still running (as will be the case if it is still being used by at least one application), restart it so that the debugging flag takes effect:

          killall fam

      The debugging information is written in the `/var/adm/SYSLOG` file. This file can be conveniently viewed with the sysmon tool, described in “sysmon, the System Log Viewer” in Chapter 2.

      | Note: Terminating `fam` while applications are using it may cause problems for those applications. If possible, terminate those applications first.

      | Note: If you are using a foreign NIS master system, see “Troubleshooting fam When Using a Sun NIS Master”.

      | Note: In the IRIX 6.5.8 release, `fam` treats clients as untrusted until they have authenticated themselves by proving that they are who they claim to be. Because `libfam` is a static archive (meaning it is compiled into each client, rather than being a shared library that can be replaced with a version that performs authentication), clients linked with the old `libfam` may not work correctly when trying to communicate with a new `fam`. For more information on troubleshooting client applications, see the `fam(1M)` man page.

## Troubleshooting `fam` When Using a Sun NIS Master

If you have the optional NIS (YP) software installed at your site, and you are using a Sun system as your NIS master, with no `rpc` entries for `sgi_toolkitbus` and `sgi_fam`, this section provides the information to correct the error message.

Depending on the operating system (the Sun 3.x or the Sun 4.0) on the Sun NIS (YP) server, one of the two following solutions applies.

- Sun 3.x

  If the Sun workstation is running version 3.x of Sun/OS, add two entries to the `/etc/rpc` database on the Sun NIS server. They are:

  - `sgi_toolkitbus` `391001`

  - `sgi_fam` `391002`

  On the NIS server, enter the command:

      cd /usr/etc/yp; make rpc

  This may take as much as an hour before the NIS server pushes this information to its clients.

- Sun 4.0

  If the Sun workstation is running version 4.0 of Sun/OS or later, add two entries to the `/etc/rpc` database on the Sun NIS server machine. They are:

  - `sgi_toolkitbus` `391001`

  - `sgi_fam` `391002`.

  On the NIS server, type:

      cd /var/yp; make rpc

  It may take as much as an hour before the NIS server pushes this information to its clients.

  | Note: If the NIS system is neither SGI or Sun server, the same `rpc` entries must be added, but the syntax may be different.

Prev | Table of Contents | Next
Chapter 7. Managing User Processes |  | Chapter 9. Using the Command (PROM) Monitor