Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"? - HP UX

This is a discussion on Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"? - HP UX ; Hi, 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 pev_NAME value Now the thing is that those environment variables are ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"?

  1. Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"?

    Hi,

    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

    pev_NAME value

    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
    my ``PEV_NAME="value"''.

    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?

    Regards,
    Ulrich

  2. Re: Bug in ServiceGuard A.11.18.00 regarding module "sg/pev"?

    Hi,

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

    Regards,
    Ulrich

+ Reply to Thread