Sybase and others start at boot

[jamesatwork]

Hello,
I think I am having an issue with some env vars not being loaded before they are required when I boot my hpux box. I have setup a script to start sybase (/sbin/init.d/sybase) and I have a link to it in /sbin/rc3.d/S377Sybase, the script is working now but only because I statically defined the SHLIB_PATH within the script itself. I have a . .//sybase set in /etc/profile but without the static definition in the startup script it will not work. Is there somewhere else I need to put the env vars so I don't have to define them in the startup scripts?

[Patrick Wallek · Accepted solution]

/etc/profile is NOT called when the /sbin/init.d scripts are run. To get it to work you MUST set any environment variables needed in the start script itself.

What you CAN do is put the '. //sybase' in the /sbin/init.d script. Then, assuming your SHLIB_PATH is set in the //sybase script, you should not need to explicitly set SHLIB_PATH in the init.d script.

[A. Clay Stephenson]

rc does initialize any beyond extremely minimal environment settings. The best way to do this is to create a script such as /usr/local/bin/sybase_env.sh and use it to set and export any needed environment variable. This script should not contain any exit or return statements.

Next your should use the shell's dot (.) operator to source this script in your .profiles, cron'ed scripts, and rc'ed scripts so that a change to this one file will fix (or break) all of your scripts.

e.g.
#!/usr/bin/sh
./usr/local/bin/sybase_env.sh
statement_1
statement_2
...
This will ensure that all of your interactive shells and scripts zig or zag as a unit.

[jamesatwork]

holy cr*p that was a quick response. thanks, I assumed that much but I was hoping that I was just missing something. If I call a file from script A will the vars cascade to script B and C etc?

[A. Clay Stephenson]

It depends. The hint I was giving was to SOURCE a file rather than invoke a child process. When a file is sourced, it becomes a part of the foreground process just as though it had always been there ---- that's why you don't put an exit or return in the sourced file because you just exited your foreground process because they are one and the same. If you invoke a child process then EXPORTED variables are sent from the parent to the child process but never in the opposite direction.

[jamesatwork]

right, but if I source a file from witing a script will those env vars be lost after that specific script exits? I will test this actually... this is a test box to be switched with prod.

[Patrick Wallek]

Yes, the variables would be lost when that script exits. Sourcing a file makes the variables available to the current running script, nothing else.

[jamesatwork]

very cool guys, thanks.. I am up and running here. How do points work on this site? You both answered at pretty much the same time.

[Patrick Wallek]

Points are at your discretion. Ideally, ALL answers **should** get some point assignment. In my opinion one should strive for 100% point assignment.

Have a look at the point assignment guidelines here and just use your best judgement.

http://forums1.itrc.hp.com/service/forums/helptips.do?#34

[jamesatwork]

thanks for your help!