ovstop — stop NNM managed processes
ovstop stops the NNM managed
processes. ovstop sends a stop
request (OVS_REQ_STOP) to the
process management process (UNIX operating systems) or service
(Windows operating systems),
ovspmd. If called with one or
more managed_process_name arguments, it
stops the designated managed processes after first stopping any
dependent processes. If called with no arguments, or if one of
the named arguments is ovspmd,
it stops all managed processes currently running, including
ovspmd itself.
When a managed process does not respond to the
ovstop request within the
LRF-specified timeout interval,
ovspmd forces the process to
terminate by sending it termination signals, first
SIGTERM, then
SIGKILL (see kill(1)). Note that
ovstop reports forced
termination only if the -v or
-coptions are used (for
example, ovstop -v
[managed_process_name]). Whenever a
managed process times out during a stop request, it is advisable
to increase its timeout value. To increase the number of seconds
that ovspmd waits for a process
to respond to an ovstop
request, follow the instructions in
$NNM_LRF/ov* (UNIX operating
system) or
install_dir\lrf\ov*
Unlike ovstart,
ovstop will not start ovspmd if it is not already running.
The managed processes are configured by ovaddobj from information in Local Registration Files (see lrf(4)). A
managed process is named by the first field in the LRF describing
it. Like ovstart, ovstop uses dependency information from the LRF. If other
managed processes depend on a managed process that is stopped, ovspmd notes their dependency and terminates all appropriate
managed processes in reverse LRF dependency order.
ovstop must be run by the
Windows administrator or UNIX superuser.
If an OVs_DAEMON process is configured with a Stop Command in its LRF entry, ovstop runs the command (see lrf(4)).
This feature is used to stop processes that are no longer in contact
with ovspmd. The Stop Command is provided and configured by the developer
of the process, if appropriate.
The names of the NNM managed processes that were started by
previous ovstart operation can be obtained by running the
ovstatus -c command.
The ovstop ovjboss command
would stop the Jboss application server and all of the NNM
services deployed together within Jboss. The names of Jboss
deployed NNM services can be obtained by running the
ovstatus -v ovjboss
command. The NNM services could only be stopped altogether by
running the ovstop ovjboss
command. It is not supported to stop any of these NNM services
individually, independent of the other NNM services.
If ovstop is used on a node configured for NNM clustering (see
nnmcluster(1M))
then the behavior of ovstop is different than described above.
Specifically, ovstop (with no parameters) behaves exactly like the "nnmcluster -shutdown" command.
In a NNM cluster environment ovstop returns immediately
(after sending the NNM cluster a shutdown signal in the background).
The nnmcluster command then shuts down NNM processes which might trigger a failover of NNM services to the standby cluster node.
Please monitor ovstatus output to determine if NNM processes have completed shutdown.
In a NNM clustered environment the only command-line options recognized by
ovstop are -nofailover,
-failover, and -cluster.
Note that for fine-grain control of NNM cluster attributes use the nnmcluster command directly.
The ovstop command in a NNM cluster environment is provided for convenience shutting down NNM services using a familiar command.
ovstop recognizes the options described below. The first
argument that is not an option, and any succeeding arguments, are
interpreted as names of managed processes to stop, and are passed to ovspmd in the stop request.
-c
Produce one line of information about the success or failure for each managed process.
-d
Report the important stages in its processing, including
contacting and sending the stop request to ovspmd, and the closing the communication channel.
-v
Produce several lines of information about the success or failure of each managed process.
-failover
(NNM cluster only) Causes the local NNM node to shutdown NNM processes (if it is the active node) and the NNM cluster process will terminate. At the same time, automatic failover is enabled so that NNM services will transfer to the standby node.
-nofailover
(NNM cluster only) Causes the local NNM node to shutdown NNM processes (if it is the active node) and the NNM cluster process will terminate. At the same time, automatic failover is disabled so that NNM services will not transfer to the standby node.
-cluster
(NNM cluster only) Causes all nodes in the NNM cluster to shutdown. The NNM cluster process on the standby node(s) will be shutdown first, then the active node will stop NNM services, and finally the NNM cluster process on the active node will shutdown.
ovstop exits with a status representing the number of managed
processes that were not stopped successfully.
If all requested managed processes were successfully stopped, ovstop exits with the status 0 (zero).
ovstop reports certain command-line errors (in particular,
too many arguments) and system errors. The messages are prefixed
with ovstop:, and are intended to be self-explanatory. ovstop also outputs error messages received from ovspmd. These messages are prefixed with ovspmd:. ovstop ignores unrecognized options.
If a managed process is in a PAUSED, PAUSE_ERROR, PAUSE_TIMEOUT, RESUME_ERROR, RESUME_TIMEOUT, or DEPENDENCY_ERR state, it is stopped. However, a warning
message is printed to inform you that ovstop was used on a process that was not in a running
state.
Note that ovspmd can
process multiple requests
(ovstart,
ovstop, or
ovstatus) at a time. If any of
these commands is being handled, the new request will be queued
by type until the previous command has completed.
The environment variables below represent universal pathnames that are established according to your shell and platform requirements. See the nnm.envvars(1) manpage for information on universal pathnames for your platform and shell.
See the nnm.envvars
reference page ((or the UNIX manpage) for information about
using environment variables for the following files:
Windows:
install_dir\bin\ovstop
Windows:
install_dir\bin\ovspmd
UNIX:
$NNM_BIN/ovstop
UNIX:
$NNM_BIN/ovspmd
If a com.hp.ov.nms.cluster.name is defined in
the $NnmDataDir/shared/nnm/conf/props/nms-cluster.properties file,
then ovstop will defer startup to the nnmcluster command.
$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.