ovspmd — NNM process management service
ovspmd
manages the service processes that are part of
NNM. It starts, stops, and reports status
on these processes in response to requests from ovstart
, ovstop
, and ovstatus
. ovspmd
is normally started automatically by ovstart
. On Windows, ovspmd
is registered as a service. ovspmd
registers under the service name HP OpenView Process Manager.
ovstart
sends a request to ovspmd
to start the object manager programs specified
in the NNM startup file (SUF), by default ovsuf
. NNM-managed processes are configured in a local
registration file (LRF), and added to the SUF by ovaddobj
. If you call ovstart
with no arguments, ovspmd
starts all managed processes configured to
be started automatically (that is, with the initial start flag OVs_YES_START
in the LRF).
ovstop
sends a request to ovspmd
to stop configured managed processes. If you call ovstop
with no arguments, ovspmd
stops all currently running managed processes,
and then exits.
ovstatus
sends a request to ovspmd
to report the current running status of configured managed processes.
Managed processes are started by ovspmd
as services (that is, in the background, with stdin
, stdout
, and stderr
ignored).
Each managed process can be configured with a dependency list
(that is, a list of other processes that must already be running
before the process can be started successfully). ovspmd
does not start a managed process until all the
processes on which it depends have already initialized successfully.
On startup, ovspmd
verifies that no LRF-specified dependencies form
a cycle. (An example of a cycle is A -> B -> C -> A
.) These dependencies determine a relative sequencing
for starting, as well as a reverse order for stopping.
ovspmd
has a mechanism to automatically restart processes that fail unexpectedly.
This process entails adding a retry count for the daemon processes as listed in the
$NNM_DATA/shared/nnm/conf/ovspmd.restart.properties file
. By default, the number of retries is 3. When a process dies
unexpectedly, this count is decremented by one until it reaches zero. At that point, the process will not be automatically
restarted. Attempting to start the process with ovstart
will reset the retry count and start the process again.
If the process has been running for two hours, then the process resets its retry counter. Removing entries will cause
ovspmd
not to do restarts. This is also true if the retry count is 0.
ovspmd
distinguishes between three classes of object managers:
OVs_WELL_BEHAVED
A well-behaved process uses the OVsPMD API (see OVsPMD_API(3))
to communicate with ovspmd
. It sends ovspmd
status information about successful and unsuccessful initialization,
normal termination and abnormal termination,
if configured to do so. ovspmd
considers a well-behaved process to have initialized
successfully only when it explicitly reports that it has done so. A well-behaved process
also exits when it receives the command OVS_CMD_EXIT
from ovspmd
.
The status information passed by the managed process to ovspmd
is forwarded to ovstart
, ovstop
, or ovstatus
, if currently running. The last message received from
each managed process is saved, and then forwarded, on request, to ovstatus
. The messages received from well-behaved processes are
also logged to the application event log (which can be examined
with the Event Viewer).
OVs_NON_WELL_BEHAVED
ovspmd
can also manage object managers that do not use
the OVsPMD
API (non-well-behaved processes) only if they
do not go into the background of their own
accord (see OVs_DAEMON
below). Because a non-well-behaved process returns no
status messages, ovspmd
considers such a process to have initialized successfully
if it is not exited within the LRF-specified timeout interval.
Non-well-behaved processes are terminated with Terminal Process if they do not exit within the configured timeout.
OVs_DAEMON
Managed processes that go into the background cannot
be managed with a communication channel or with signals. ovspmd
can start such a process, but it cannot stop or report
meaningful status about the process because it does not have a communication
channel or a process ID for it.
install
Install ovspmd
as a service.
start
Start the ovspmd
service.
stop
Stop the ovspmd
service.
remove
Remove the ovspmd
service.
-W
Do not start managed processes when ovspmd
starts. Wait for ovstart
to request it.
-d
Used for debugging. When used, ovspmd
does not become a service.
-V
Run in very verbose mode. In this mode, ovspmd
outputs very detailed information about the configuration
of the managed processes. This is far too much information for ordinary
use.
-f startup_file
Read startup_file
as the startup file (SUF) instead of the default. Note
that startup_file
must be an absolute path.
ovspmd
governs the management of NNM services. It uses
the ovspmd.auth
file to control which hosts, users, and applications
can start and stop the NNM services. The ovspmd.auth
file is located in
.data_dir
\shared\nnm\conf\
ovspmd
searches the entries in the ovspmd.auth
file from beginning to end. As soon as it finds
an entry that either explicitly allows or denies the access under consideration,
it stops looking. Therefore, more specific entries should precede
more general entries.
The file contains lines specifying the authorized hosts, users,
and applications. Each line lists a single host, user, and application
list authorized to connect to ovspmd
. The format of each line of the file is:
#
comment
hostname
[username
[appname1
appname2
appname3 ...
]]
The pound sign (#
) and anything following it is a comment, which is
ignored. Blank lines are also ignored.
and username
are optional. If no application is present, the
line permits (or denies) access by any application. If no username
is present, the line permits (or denies) access by any user running
any application.appname
If
is a plus sign (hostname
+
), the line refers to access from any host.
If
is a plus sign (username
+
), the line refers to access by any user.
If a hostname is preceded by a minus sign (-
), the line explicitly denies all
access from that host. (Any username or application names that
also happen to appear on the line are ignored.) If a username is
preceded by a minus sign (-
), the line explicitly denies any access by that user
from the specified host. (Any application names that also happen
to appear on the line are ignored.)
If any applications are listed, the line permits access only to the applications listed (by the specified user from the specified host). Note that the application names listed in the authorization file must match the registered name of the application, except that white space in the registered application name must be replaced with underscores.
The ovspmd.auth
file created at installation contains more examples
of the file format, and some examples are also included in the EXAMPLES
section.
ovspmd
issues error messages about configuration
errors and system call failures. These messages are intended to
be self-explanatory. If it currently has an open communication channel
with ovstart
, ovstop
, or ovstatus
, ovspmd
forwards these error messages through the communication channel
to be output by the program.
ovspmd
can process multiple requests (start, stop, or status) at a time. Additional requests are queued by type until
the current request completes.
In addition, ovspmd
logs processing, configuration, and system errors
using nettl
in the OVS subsystem at the ERROR
level. Messages
indicating normal events, such as successful initialization, are
logged at the INFORMATIVE
level. Messages indicating initialization
failure or abnormal termination are logged at the WARNING
level.
The following is an example of the contents of the ovspmd.auth
file:
# Normally, you should authorize any application # run by any user on the same host on which ovspmd is running. # To do so, use a single line listing the # name of the host on which this file is located # (for example, "thishost"): thishost # Similarly, if you are running Management # Consoles, you should authorize any application # run by any user on all the client hosts and on # the server host. For example, if your server # system named "bigsystem" has one client named # "hohum", list each of them on a separate line in # this file on bigsystem: bigsystem hohum # It is possible to permit specific users to run # specific applications from a remote system. The # following line permits the user "shem" from host # "blimp" to run the applications "Toaster Manager" # and "Blender". Note that, because the application's # registered name "Toaster Manager" contains white # space, you must replace the whitespace with the # underscore character in the authorization file: shem blimp Toaster_Manager Blender # It is not possible to exclude specific applications, # except by explicitly permitting all non-excluded # applications. # The following line denies access by the user "fred" # from any host: + -fred # The following line denies any application access # from the host "badguy": -badguy
See the nnm.envvars
reference page (and the UNIX manpage) for information about using environment
variables for the following files:
install_dir
\bin\ovspmd
install_dir
\conf\ovsuf
See $NNM_DATA/shared/nnm/conf/ovspmd.restart.properties
for restart property configuration.
$LANG
provides a default value if the internationalization
variables, LC_ALL
, LC_CTYPE
, and LC_MESSAGES
are unset
, null
, or invalid
.
If $LANG
is unset
, null
, or invalid
, the default value
of C
(or English_UnitedStates.1252
on Windows) is used.
LC_ALL
(or $LANG
) determines the locale of all other processes
started by ovspmd
.
LC_CTYPE
determines the interpretation of text as single-byte characters,
multiple-byte characters, or both; the classification of characters as
printable; and the characters matched by character class expressions
in regular expressions.
LC_MESSAGES
determines the language in which messages are
displayed.
All other environment variables are inherited from the shell
executing ovspmd
(or the initial ovstart
that starts ovspmd
). ovspmd
and all service processes share this same environment.
As a result, ovspmd
must be stopped and restarted for any environment
changes to take effect (see ovstart(1M)).