Managing Serviceguard Eighteenth Edition, September 2010
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 387).
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
390 Cluster and Package Maintenance