DBserver on Linux startup issue

Hi guys,
I’m having a little issue here.
I’m installing a DBServer on Linux for tests and the issue is that if I start it from command line (run.sh) it works fine, clients can do queries and stuff. However if I start it via SCI then seems it can’t get the Environment variables I declared on bashrc (Oracle ones) and can’t make it work, getting error code 1127. Any idea on how to solve this? Seems to be how LCA sends the start command but can’t figure out how it does the execution.

This is my bashrc Oracle variables:

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe export ORACLE_SID=XE export NLS_LANG=`$ORACLE_HOME/bin/nls_lang.sh` export ORACLE_BASE=/u01/app/oracle export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH export PATH=$ORACLE_HOME/bin:$PATH

Thanks

The user account under which is the LCA running has these environment variables in his profile?Try to log in under this account and look at the env or try to restart LCA, I remember that in a past I have registered similiar issue, when the LCA was badly cached the profile.

LCA is running under root, the same account I’m using to start the DBserver manually, the Cfg DBserver does work fine but of course a starting it manually…really don’t understand what am I missing…

Could you post logs fragment covering the error message?

Last time I had similar case and I didn’t have time to solve it properly so I added oracle exports to lca startup script

Well this worked…but why…then what environment variables does LCA uses??

Added the variables to bash_profile instead of bashrc and same bad behavior. Launching manually does work fine…

Well created a custom script inside /etc/profile.d/ (gcti.sh) and still didn’t work…
Adding to /etc/environment fucked the system
Continuing tests

Well modifying /etc/environment properly seems to be the path, but now the listener doesn’t start…
Seems easiest way is just to declare variables under LCA (/etc/init.d/gctilca) script… as bublepaw suggested

you can also add variables to run.sh in DBServer directory and change application option ‘command line’ in CME from multiserver to run.sh. This should also work just fine and doesn’t need to restart lca if this is case for you.

Why not? modifying LCA init.d script does the job…once and done. Not like a change that has to be done everytime.

Kubig, Why is that? The important thing in production is that it works and is stable, all of these solutions meet that requirement.

On all varieties on Unix you need to force LCA to pick up the profile before calling the application.

The only thing I wouldn’t allow in production is applications running as root.

Gee Kubig how continuously you change Database client software? You add only to LCA script the Oracle variables needed and same to bashrc. So how many? 2.
Why would adding another global environment variable would affect the already existing ones? Sometimes you really just exaggerating everything man… chill down a little bit… and coming from me says a lot lol…
Don’t try to find the 5th leg to everything you see because it is not like that…