Re: Agent restarts and .bash_profile

From: Dave Herring <gdherri_at_gmail.com>
Date: Mon, 14 May 2018 16:11:01 -0500
Message-ID: <CAFN=diA9FB04jTqCjbvEqPFJpnmBqiwCrZJuTMZzJa+5UZJW7A_at_mail.gmail.com>



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_at_gmail.com> 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_at_uwo.ca> 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 through
>> OEM,
>> > the appropriate ".*profile" is not sourced, corresponding to which
>> account
>> > you run the agent as? That's a rather confusing sentence so restating
>> with
>> > examples:
>> >
>> > If I restart the management agent in OEM and we run the agent under the
>> OS
>> > account "oracle", I'd expect at some point "~oracle/.bash_profile" to be
>> > 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
>> "cat
>> > /proc/<AGENT'S PID>/environ | xargs -n 1 -0" I don't see these
>> variables.
>> >
>> > 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
>> home
>> > 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
>

-- 
Dave

--
http://www.freelists.org/webpage/oracle-l
Received on Mon May 14 2018 - 23:11:01 CEST

Original text of this message