HP Serviceguard manual Resetting the Service Restart Counter, Cmmodpkg -R -s myservice pkg1

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-scommand. 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