Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"?
I was developing some scripts to be used with HP ServiceGuard 11.18
(+PHSS_37602) in a "modular package". The module "sg/pev" promises to set
environemnt variables as specified with
Now the thing is that those environment variables are not set as documented,
and even if they are set, everything is capital letters, so I wonder why the
example uses "pev_" instead of "PEV_".
Inspecting the environment of my "external_script", I find many SG-related
variables, but not the ones configured. Instead I find a variable
"SG_ENV_FILE" with a value like
"/var/tmp/master_control-script_env.PACKAGE.3235". That file contains about
every ServcieGuard setting as variable assignment in shell syntax, including
However this is not what's documented, and it makes little sense: How should a
"script" that is not POSIX-shell set up the environment? "SG_ENV_FILE" is not
mentioned in any comment, so I guess ServiceGuard should have set up the
environment from the file, not the user's servcie script.
(I was doing a "cmcheckconf -P package")
There is a shell function named "sg_source_pkg_env" that is expected to set up
the environment. Another comment in the master_control_script.sh says that
when validating, the file name of the environemnt file is passed as additional
parameter to the script. Funny, but I'd prefer the environment to be set!
(The other thing that sounds stupid to me is that I cannot "cmcheckconf -P
package" while the package is up. So I cannot prepare the next configuration
for a package while the package is up. Probably this is because cmcheckconf
and cmapplyconf is basically the same program...)
Can anybody bring some light into this?
Re: Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"?
I've learned more about ServiceGuard: It seems to be not a bug, but a feature!
Different cultures may have different expectations regarding what is
considered logical and simple. What ServiceGuard currently offers is this:
You can configure the setting of environment variables in a modular packages's
configuration file. When one of your scripts that are going to "receive" those
environment variables starts, it has to do the following:
1) get an environment-variable to construct a path to a shell script that is
to be sourced to get additional functions.
2) Call one of these functions to get your environment set. That function then
basically sources another file where commands to set the environment are.
I don't understand why ServiceGuard isn't simply setting the environment
variables before starting a script. I solved my problem more elegantly by
writing a wrapper-script that sets the environment before calling the actual
script. That even allows per-script environment variables...