Child process environment variable inheritance

[Kevin Bingham]

Hi Everyone,

I am trying to understand some strange behaviour that I am getting with a customer's HP-UX machine.

First, some background...
As I understand things, in Unix (generically) when one process invokes a subprocess, that subprocess inherits the environment of its parent process. On the back of that understanding, some description of the problem. I have a scenario where a script scr1.sh invokes a load module LM1 that stays running until you tell it to stop. LM1 then reads a database and processes work requests, which then result in the calling of a new script (scr2.sh), which in most cases either call another loadmodule (LM2) of our own, or, a load module belonging to the product we support (LM_EXTERNAL_1).

Now, with that as a backdrop (calling chain of scr1.sh->LM1->scr2.sh->LM2), I would expect the environment setup in scr1.sh to be available for LM1, scr2.sh and LM2 (and on our own HP and AIX machines, as well as those of most of our customers, this is the case).

The problem is that at one specific customer, the SHLIB_PATH environment variable is not the same when "tested" in scr2.sh, which means that LM2 fails due to "missing Shared Library" errors. Strangely, it seems that SHLIB_PATH is the only environment variable that "gets lost".

Our Scripts use the Bourne Shell if that matters.

Can anyone help me understand what is causing this behaviour, and possibly how to resolve it?

I know a work around would be to hard code the value of SHLIB_PATH in scr2.sh, but scr2.sh represents 100 possible scripts... so I would prefer not to go down that route.

Thanks in advance, points rewarded for every reply...

Kevin

[Steven E. Protter]

Shalom Kevin,

I'd create a central environment script and source it into the scripts.

You can use sed to turn a comment hash mark # into the command that makes all 100 scripts properly read SHLIB_PATH

You might also find a universal value for SHLIB_PATH that works for that system.

SEP

[Kevin Bingham]

Thanks for the tip SEP, I may use it... but that does not explain why this is behaving like this in the 1st place.

Kevin

[A. Clay Stephenson]

Note that it is entirely possible for LM1 to alter its environment through putenv and thus affect the environment of any child processes. That are also some linker and linker tools patches that deal specifically with SHLIB_PATH being ignored or modified -- so this could be a diffence in patches on the various boxes. Since you didn't bother to identify the OS, it's difficult to be specific. Now, I'll tell you what I consider to be the most likely explanation: An improper use of putenv() in LM1. Pay particular attention to this man page referefence: "A potential error is to call putenv() with an automatic variable as the argument, then exit the calling function while string is still part of the environment." This can lead to code that works by accident on some platforms and fails on others.

[Peter Gillis]

Kevin, this most probably very basic.. but thinking along the lines of keeping it simple!
Have you checked that the SHLIB_PATH is exported.... export SHLIB_PATH=.....
Also, is there a soft link missing? Does the missing shared library need to be a link file?

regards,
Maria

[Kevin Bingham]

Hi Everyone,

Thanks for the suggestions. I got to the bottom of it and here are the details:
My scripts use the POSIX shell and the customer had setup their users to use the ksh by default. The behaviour was explained by the customer usr's $HOME/.kshrc having only the "export sHLIB_PATH=/lib1:/lib2" inside it. It seems that if a ksh process starts a posix-sh process, which in turn starts child process, then the ksh "profile" overlays any inherited environment from the posix-sh process. I put some logic into the $HOME/.kshrc to use some posix-sh defined variables, which if blank defaulted to a valid value, and then set SHLIB_PATH using these.

Problem solved... Issue closed.

[Kevin Bingham]

see previous post