HP Serviceguard A.11.20- Managing Serviceguard Twentieth Edition, August 2011

Resetting the Service Restart Counter
The service restart counter is the number of times a package service has been automatically restarted.
This value is used to determine when the package service has exceeded its maximum number of
allowable automatic restarts.
When a package service successfully restarts after several attempts, the package manager does
not automatically reset the restart count. You can reset the counter online using the cmmodpkg -R
-s command. For example:
cmmodpkg -R -s myservice pkg1
The current value of the restart counter is shown in the output of cmviewcl -v.
Allowable Package States During Reconfiguration
In many cases, you can make changes to a package’s configuration while the package is running.
The table that follows shows exceptions — cases in which the package must not be running, or in
which the results might not be what you expect — as well as differences between modular and
legacy packages.
CAUTION: Be extremely cautious about changing a package's configuration while the package
is running.
If you reconfigure a package online (by executing cmapplyconf on a package while the package
itself is running) it is possible that the package will fail, even if the cmapplyconf succeeds,
validating the changes with no errors.
For example, if a file system is added to the package while the package is running, cmapplyconf
does various checks to verify that the file system and its mount point exist. But the actual file system
check and mount of the file system can be done only after cmapplyconf succeeds; and if one of
these tasks fails in a running package, the entire package will fail.
Another example involves renaming, modifying, or replacing an external script while the package
that uses it is running. If the package depends on resources that are managed by the script, the
package will fail when you replace the script. See “Renaming or Replacing an External Script Used
by a Running Package” (page 312).
As a rule of thumb, configuration changes which would have prevented a package that was
changed offline from starting, will very probably cause the package to fail if the changes are made
while the package is running. Be particularly cautious about adding, removing, or changing logical
volumes, volume groups, or file systems.
For any change you intend to make, read the information in the table carefully, and try out changes
on a non-production package before applying them to a running production package.
In general, you have greater scope for online changes to a modular than to a legacy package. In
some cases, though, the capability of legacy packages has been upgraded to match that of modular
packages as far as possible; these cases are shown in the table. For more information about legacy
and modular packages, see Chapter 6 (page 227).
NOTE: If neither legacy nor modular is called out under “Change to the Package”, the “Required
Package State” applies to both types of package. Changes that are allowed, but which HP does
not recommend, are labeled “should not be running”.
IMPORTANT: Actions not listed in the table can be performed for both types of package while
the package is running.
In all cases the cluster can be running, and packages other than the one being reconfigured can
be running. And remember too that you can make changes to package configuration files at any
time; but do not apply them (using cmapplyconf or Serviceguard Manager) to a running package
in the cases indicated in the table.
314 Cluster and Package Maintenance