It's not necessarily for the agent itself but anything that runs in the
Oracle environment.
A long, long time ago we only had maybe 20 or 30 database servers and our
standard set of shell scripts was maintained on a NAS. The NAS was mounted
on all db servers and to aid in making things consistent we set "export
NAS=<NAS path>" in all ~oracle/.bash_profile. This was before OEM so
everything was in cron and our cron commands were similar to ".
~oracle/.bash_profile; $NAS/admin/shell/<script name>".
Now we have hundreds of db servers and nearly all jobs run out of OEM. We
use the convention of "$NAS" as the starting location of all scripts.
Behind the scenes that location could be one place or another. $NAS is
defined during installation and set in ~oracle/.bash_profile so after that
point ~oracle/.bash_profile is the key for setting the Oracle env. In
LDAP'ed servers our standard is just to source ~oracle/.bash_profile in our
own ~/.bash_profile to make sure we'll all setting the same env.
Within the parameter settings for OEM Jobs we typically have each OS
command start with "~oracle/.bash_profile" but at one point I questioned
why, because I was under the incorrect assumption that
~oracle/.bash_profile would be sourced regardless of how the process was
created or I suppose more correctly regardless of whether or not the
process was interactive. We had a situation where ~oracle/.bash_profile
wasn't the first command sourced in an OEM OS command Job and that wasn't a
problem until I upgraded all agents and found that $NAS wasn't set in any
of the agent's envs.
I got curious why $NAS wasn't set and started poking around and couldn't
come up with any good reasons so I figured I'd through it out on this
list. I will happily accept (well, at least pretend to happily accept) all
sorts of criticism on how we set our envs, run our jobs, etc.
Dave
On Mon, May 14, 2018 at 3:41 PM, Niall Litchfield <
niall.litchfield@xxxxxxxxx> wrote:
Will is exactly correct. the profile files are intended for interactive
sessions. Cron behaves in the same way for example.
I'm somewhat surprised that you are setting variables for the agent
process? What is it that you achieve by this?
On Mon, May 14, 2018 at 8:27 PM, Will Beldman <wbeldma@xxxxxx> wrote:
According to the bash manpage, there are very specific rules about when
the
.bash_profile/.bashrc/.profile files are picked up.
.bash_profile is only read if the shell is interactive or if it isn't but
you
also supplied --login. Presumably, restarting the agent does not do
either (it
must be a non-interactive shell that doesn't supply --login).
So assuming restarting the agent is classified as "non-interactive", from
how
I read the manpage, you could get away with setting BASH_ENV as
"~oracle/.bash_profile" first, then restarting the agent.
Alternatively, there could be other config files you supply for the agent
that
I'm not knowledgeable enough to comment on.
On Monday May 14 2018 01:43:40 PM Dave Herring wrote:
Does anyone know WHY when restarting Oracle's management agent throughOEM,
the appropriate ".*profile" is not sourced, corresponding to whichaccount
you run the agent as? That's a rather confusing sentence so restatingwith
examples:OS
If I restart the management agent in OEM and we run the agent under the
account "oracle", I'd expect at some point "~oracle/.bash_profile" to be"cat
sourced within the agent's environment. Yet I know this doesn't happen
because we have a couple of important env variables set in
~oracle/.bash_profile and when checking for these using something like
/proc/<AGENT'S PID>/environ | xargs -n 1 -0" I don't see thesevariables.
home
I've checked this under RHEL and Oracle 11g / 12c. I first noticed the
issue when applying the latest agent PSU to a group of agents via an OEM
plan, then validated the same situation happens if, under the agent's
page, I restart it in OEM. Normally all management agent restarts are
performed in a standard script we have which runs through stop, start,
clearstate, upload, status for the given agent, among other things.
--
Niall Litchfield
Oracle DBA
http://www.orawin.info
