When I try to login, I get the message:

               LOGIN: ERROR- Failed to initialize policy manager.(IFOR_PM_FATAL)
               Login session denied.

          This occurs shortly after logging in and obtaining a shell
          prompt.  My session then terminates and a login prompt is
          again displayed.

          Either the SCO Policy Manager, /etc/ifor_pmd, has died and not
          restarted, or some crucial file required by the Policy Manager
          to satisfy the login request is missing or corrupted.  Listed
          below are the possible specific sources of corruption or
          malfunction:

          (

      The corresponding steps to take to remedy the situation
          are then listed in the SOLUTION area of this article.)

          1. The /etc/ifor_pmd binary is corrupted or missing.

          2. The directory /pmd and/or its contents, the named streams pipes
             IPCCT_pipe, PMDCT_pipe, LST_pipe, and the file ifor_pmd.pid,
             are corrupted or missing.

          3. The root filesystem is mounted read-only.

          4. No user licenses exist on the system, or there are no more
             user licenses to check out.

          5. Required kernel resources to handle the login request
             are not available on the system.  This can be a consequence of
             upgrading a 16+ user SCO Unix 3.2v4.2 or Open Server 3.0 system
             to SCO OpenServer 5, or even adding User License Upgrades,
             among other causes.

           6. The CMOS date has been set to a date that is before May 1995.

          Here are the corresponding steps to take for the cases enumerated
          above.  Wherever relevant, SCO OpenServer Enterprise System
          is considered for the sake of providing a definite example.

          1. The /etc/ifor_pmd binary is corrupted or missing.

          In the Software Manager, choose Software->Verify Software
          ->Broken/missing symbolic links, in order to check and possibly
          repair a missing link from /etc/ifor_pmd to the /opt/K/SCO
          hierarchy.  You can perform this operation on the Policy Manager
          package alone by selecting SCO OpenServer Enterprise System->
          SCO OpenServer Enterprise System Unix->SCO OpenServer Enterprise
          System Core OS->Base Operating System->Policy Manager.

          If the ifor_pmd binary is actually missing from the /opt/K/SCO
          directory tree, you can use the customextract(ADM) command to
          install a single file from the installation media.  In the
          case of cdrom media and the cdrom device /dev/cd0, the command
          would be:

               customextract -m /dev/cd0 /opt/K/SCO/Unix/5.0.0Cl/pmd/ifor_pmd

          2. The directory /pmd and/or its contents, the named streams pipes
          IPCCT_pipe, PMDCT_pipe, LST_pipe, and the file ifor_pmd.pid,
          are corrupted or missing.

          Again, the procedure in item 1 (to check for broken or missing
          symbolic links) may be invoked, since /pmd on an uncorrupted
          system is a symbolic link to a directory in the /var/opt
          hierarchy.  If /pmd exists, but any of its file contents do not,
          they may be restored by stopping and restarting /etc/ifor_pmd.
          In order to do this, perform these steps:


            a. Enter the command "ps -ef|grep ifor_pmd|grep -v grep", to
               which you should be returned two lines similar to this:

               root 41     1  0   Aug-29       ?    00:00:00 /etc/ifor_pmd
               root 42    41  0   Aug-29       ?    00:00:04 /etc/ifor_pmd

               Any of the numbers shown may vary on your system, with the
               exception that one of the entries should have "1" in the
               third field (parent process ID).  This is the "parent" copy
               of ifor_pmd, and the other entry is the "child", whose parent
               process ID should match the second field (process ID) of the
               parent entry.

            b. Kill the child ifor_pmd.  In the case above, the command
               would be:

               kill 42

            c. In a few moments, run the command in item "a." again.  You
               should observe that a new child ifor_pmd is running.

            d. Check the contents of /pmd.  You should see four files:

               IPCCT_pipe
               PMDCT_pipe
               LST_pipe
               ifor_pmd.pid


          3. The root filesystem is mounted read-only.

          This has been identified by SCO as a distinct reason for
          pmd-related failures.  It is only expected, however, in rare
          circumstances.  Of course, in these cases, other write failures
          to /dev/root may be expected, with other errors obtained.

          In practice, it is sufficient to check this by examining the
          file /etc/default/filesys for nondefault root filesystem
          settings, such as "mountflags=-r" or "mntopts="-o ro"".  If
          such settings are found, remove them.


          4. No user licenses exist on the system, or there are no more
             user licenses to check out.

          First, determine how many users are already logged in to the
          system.  The user counting should be done on the same basis
          as that defined by the Policy Manager; a user is defined as
          a distinct physical keyboard OR a login over the network.
          If indeed the system has run out of licenses to check out,
          the only way to avoid the error message is to add user
          licenses by purchasing an additional-user license product.

          If the login user count has not been exceeded, it is possible
          that the license database itself has been corrupted.  Follow
          the steps below to re-apply the user licenses on the system.
          This procedure assumes that user licenses are supplied only
          through the SCO OpenServer Enterprise System Certificate of
          License and Authenticity.  If you have already licensed
          additional users with a separate user-license product, apply
          the procedure to that product _first_.

            a. Tell all users to log off the system.

            b. When all users are logged off, invoke the License Manager,
               select "SCO OpenServer Enterprise System", and choose
               License->Remove License, to remove the SCO OpenServer
               Enterprise System license.

            c. Re-license and register the SCO OpenServer Enterprise
               System, choosing the appropriate options in the License
               Manager.

            d. Run the command discussed in 2a) above, in order to check
               whether the Policy Manager is running.  Usually in the
               present set of conditions, the Policy Manager will _not_
               be running.  Hence, if the command in 2a) shows that
               two instances of the /etc/ifor_pmd process are not running,
               simply issue the command

               /etc/ifor_pmd

               to restart the Policy Manager Demon.  Again perform the
               command in 2a) to verify that two instances are indeed running.

            e. Tell users to log back in to the system.


          5. Required kernel resources to handle the login request
             are not available on the system.

          In these cases, rebooting the system may temporarily workaround
          the problem, but re-occurrence is inevitable.

          Issue the command "netstat -m" and note the number under
          the "fail" column on the first line of output for "streams".
          If this number is nonzero, then increase the NSTREAM kernel
          tunable by running /etc/conf/cf.d/configure or by running the
          Hardware/Kernel Manager in the System Administration folder.

          If no "streams" failures are noted as above, other kernel
          changes may be required pertaining to streams and the mechanism
          which the system uses for communicating license requests between
          the Policy Manager and the login binary.  This mechanism is
          called "Unix Domain Sockets".  The utility /etc/tunek is provided
          to increase resources related to Unix Domain Sockets that are
          necessary for the licensing scheme to function.  Try running the
          tunek utility as follows:

          /etc/tunek -l user -n <number of additional users to tune for>

          where <number of additional users to tune for> is a reasonable guess
          of the number of additional user resources, _and_ must be chosen
          from the following list: 10, 25, 50, 100, 500, 1000.  For example,
          the following command should be used if the system has newly
          installed SCO OpenServer 5 which has employed a 64-user Open Server
          3.0->64-user OpenServer 5 upgrade license:

          /etc/tunek -l user -n 100

          

      kernel relink is necessary after running the tunek utility.
          Make sure you remember to run /etc/conf/cf.d/link_unix after
          running tunek, as the tunek utility will generally not prompt the
          user to relink.

          The tunek utility is run automatically when a User License Upgrade
          product (sometimes referred to as a user bump, bump pack, or license
          pack) is added to the system, after the user enters "Y" to a prompt
          to re-tune the system (upon exiting the License Manager).  If, after
          applying one of these user bumps, the "Failed to initialize policy
          manager" error persists, then it might be necessary to run tunek
          again, incrementing the user license resources (by perhaps 25 or 50).
          It may also be necessary to run the Network Configuration Manager
          to increase socket connections and the number of pseudo ttys related
          to network-based logins, if most logins on this system are via
          utilities such as telnet or rlogin.

          

      for most 16+ user upgrade licenses from a pre-OpenServer 5
          release to an OpenServer 5 release (e.g., Unlimited-user Open Server
          Enterprise 3.0.0 -> 64-user OpenServer Enterprise System 5), the
          tunek utility is _not_ automatically run.  These systems are
          especially prone to pmd initialization failure upon login attempts
          after a large number of users have already been logged in, because
          of socket and streams resource shortages.  A telltale sign of the
          problem is that the onset of the error occurs after a large number
          (say, 50 or so, in a system licensed for 64 users) of users have
          already been logged in, but the exact number varies between reboots
          of the system.  This problem has been fixed in the upcoming release
          of SCO OpenServer 5.

           6.  Login as root user at tty01 console screen and enter "date"
           at the command prompt.  If the date is before May 1995 then reboot
           to CMOS system and set the correct date.  If this occurs often
           replace the system CMOS battery.

          Other articles in this database:

          "Licensing Policy Manager Daemon (ifor_pmd) has terminated"
          at boot time. (Technical Article 104744)

          "No user licenses were found on this machine" error and system
          panics. (Technical Article 104755)

          The policy manager daemon dies and is unable to restart
           (Technical Article 104803)