Re: Agent restarts and .bash_profile

You had me at "pretend to happily accept" :).

I'd suggest that scripts either *always* source a common .env file that sets $NAS etc, or else check that it is set before using it. - much like oraenv is intended to be used (but everyone reinvents) :)

On Mon, May 14, 2018 at 10:11 PM, Dave Herring <gdherri_at_gmail.com> wrote:

> 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
>

-- 
Niall Litchfield
Oracle DBA
http://www.orawin.info

--
http://www.freelists.org/webpage/oracle-l