Try
TA # 104851 which has the following (advise to use the link in case some of the other cases under "See Also" are valid for your problem)
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
NOTE: 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.
NOTE: 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.
See Also
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)
07-21-2004
