Name

ovspmd — NNM process management service

SYNOPSIS

ovspmd [ [install] [start] [stop] [remove] [-W] [-d] [-V] [-f startup_file] ]

DESCRIPTION

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.

Parameters

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.

Application Authorization

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.

username and appname 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.

If hostname is a plus sign (+), the line refers to access from any host. If username is a plus sign (+), 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.

DIAGNOSTICS

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.

EXAMPLES

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

AUTHOR

ovspmd was developed by Hewlett Packard Enterprise.

FILES

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.

EXTERNAL INFLUENCES

Environmental Variables

$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)).

SEE ALSO

ovstatus(1), ovstart(1M), ovstop(1M), ovaddobj(1M), ovdelobj(1M), nnmcluster(1).

Return to Reference Pages Index