From: Laurenz Albe on
DA Morgan <damorgan(a)psoug.org> wrote:
>>> Two other suggestions if what has been recommended, so far, doesn't work.
>>>
>>> 1a. ps -ef | grep libora
>>> 1b. kill -9
>>>
>>> 2. reboot
>>
>> Reboot on a unix ( aix ) system? Why in the heck would you recommend
>> something like that for a problem based on oracle software
>> installations?
>
> Because sometimes, with AIX, it works.

Sure, just like buying a new lamp will fix a broken lightbulb :^)

If it is a shared library that is still loaded in memory, all you have to
do on AIX is to say 'slibclean' as user root.

Yours,
Laurenz Albe
From: hpuxrac on

DA Morgan wrote:
> hpuxrac wrote:
> > DA Morgan wrote:
>
> >> Two other suggestions if what has been recommended, so far, doesn't work.
> >>
> >> 1a. ps -ef | grep libora
> >> 1b. kill -9
> >>
> >> 2. reboot
> >
> > Reboot on a unix ( aix ) system? Why in the heck would you recommend
> > something like that for a problem based on oracle software
> > installations?
>
> Because sometimes, with AIX, it works.

Bad advice is just bad advice. If you want to describe a specific
situation on an aix box where re-booting was the only solution and give
the details then let's hear it.

Otherwise it's probably better to give advice to find and talk to a
knowledgeable aix system administrator rather than throw in the
"reboot" recommendation. It shows someone without ( apparently ) a lot
of unix experience trying to cause other oracle professionals to pick
up bad habits.

From: EdStevens on

DA Morgan wrote:
> EdStevens wrote:
> > DA Morgan wrote:
> >> EdStevens wrote:
> >>> Platform: AIX Version 5.3 patch/maintenance level 05
> >>>
> >>> Installed Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 -
> >>> 64bit. Runing fine.
> >>>
> >>> Installed agent in it's own oracle home:
> >>> Oracle Enterprise Manager 10g Release 10.2.0.1.0.
> >>> Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
> >>> ---------------------------------------------------------------
> >>> Agent Version : 10.2.0.1.0
> >>> OMS Version : 10.2.0.2.0
> >>> Protocol Version : 10.2.0.0.0
> >>>
> >>>
> >>> Trying to apply patchset 3731593 to bring agent up to 10.2.0.2.0.
> >>> Logon as 'oracle', set ORACLE_HOME to the agent's home, manually
> >>> stopped the agent, navigated to <patchset>/Disk1 and fired up
> >>> runInstaller. OUI came up, ran some checks and asked some questions,
> >>> all as expected, confirmed the components to install, but then
> >>> reported:
> >>>
> >>> Error writing to file
> >>> '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so'
> >>> [/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so
> >>> (Cannot open or remove a file containing a running program.)]
> >>>
> >>> Ideas?
> >> What did you do that you think stopped the agent?
> >>
> >> My guess is you stopped some other agent in some other directory based
> >> on your path.
> >>
> >> cd $OMA_HOME/bin -- go to the home directory
> >> pwd -- verify you are really there
> >> ./emctl stop agent
> >> ./emctl status agent
> >>
> >> On my list of egregious Oracle design errors has been that they put
> >> emctl into every home directory they could spell. ;-)
> >> --
> >> Daniel A. Morgan
> >> University of Washington
> >> damorgan(a)x.washington.edu
> >> (replace x with u to respond)
> >> Puget Sound Oracle Users Group
> >> www.psoug.org
> >
> > Good point about the 'extra' emctl files laying around. But even when
> > insureing against that problem as you detailed, the results were the
> > same.
>
> What's the same?

1) Just set ORACLE_HOME and issue 'emctl stop agent' results in "Error
writing to file
'/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..."

2) set home, cd to home, issue "./emctl stop agent" results in "Error
writing to file
'/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..."


>
> Two other suggestions if what has been recommended, so far, doesn't work.
>
> 1a. ps -ef | grep libora
> 1b. kill -9
>

"ps -ef | grep libora" returns nothing but the grep process itself.
Tried this both before firing up runInstaller and in a separate session
while the OUI was waiting on me to respond to the error message.

While driving to the office this morning I had a "DOH!" moment when I
realized that I could very well have been picking up a previously
installed version. So after setting ORACLE_HOME appropriately and
navigating to the Disk1 directory of the patchset, I issued 'which
runInstaller'. It reported the one in the current directory. Just for
grins, I tried specifying it explicitly anyway, with '$>
../runInstaller'. Same result as all previous efforts.

I'll try to get the SA to issue an 'slibclean'. Also, will add 'set
-x' to the runInstaller script and examine exactly what's getting set
in the environment and what decisions are being made.


> 2. reboot
> --
> Daniel A. Morgan
> University of Washington
> damorgan(a)x.washington.edu
> (replace x with u to respond)
> Puget Sound Oracle Users Group
> www.psoug.org

From: DA Morgan on
EdStevens wrote:
>> What's the same?
>
> 1) Just set ORACLE_HOME and issue 'emctl stop agent' results in "Error
> writing to file
> '/db01/app/oracle/product/agent10g/oui/lib/aix/liboraInstaller.so ..."

That may well be part of the problem. The emctl in ORACLE_HOME is not
the correct emctl to stop the EM agent. It is the emctl that stops the
dbconsole agent.

As I stated earlier ... Oracle has put the emctl executable in every
home they can find. It is often the problem not the solution.

HTH
--
Daniel A. Morgan
University of Washington
damorgan(a)x.washington.edu
(replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org