Re: Beware of OPatch.....

From: MARK BRINSMEAD <mark.brinsmead_at_shaw.ca>
Date: Mon, 06 Feb 2006 10:18:03 -0700
Message-id: <1c0a4911c09416.1c094161c0a491@shaw.ca>

Or, at the very least, maybe OPatch could check the exit status for the 'ar' command it *thought* it invoked, and maybe take appropriate action if it failed...

After all, it is also possible to find the *wrong* 'ar' executable in your $PATH...

Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C62B3F.80E829BE"

------_=_NextPart_002_01C62B3F.80E829BE
Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Here's a nice one......

Running opatch 1.0.0.0.54, applying one-off patch to 9.2.0.6 on Sparc Solaris 5.9 64-bit.

In my environment, the 'ar' binary (which Opatch uses to replace objects in libraries) is in /usr/ccs/bin and as it happens, was not in the oracle users' default $PATH.

Well, OPatch does NOT check if 'ar' is in it's path before proceeding. The result is, if 'ar' is NOT in the $PATH, OPatch overwrites the library being patched w/ a zero-length file!

Yeah, not only does it not work, it cripples the $ORACLE_HOME!

Nice, eh?

Just a cautionary tale, in hopes others will avoid the pain I went through.

-Mark

PS I have filed an enhancement request to have OPatch check for 'ar' before proceeding....

--
Mark J. Bobak
Senior Oracle Architect
ProQuest Information & Learning

"There are 10 types of people in the world:  Those who understand
binary, and those who don't."
 <<Bobak, Mark.vcf>>=20

------_=_NextPart_002_01C62B3F.80E829BE
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable



<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>

<HEAD>

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =

charset=3DUS-ASCII">


<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =

6.5.7638.1">


<TITLE>Beware of OPatch.....</TITLE>

</HEAD>

<BODY>

<!-- Converted from text/rtf format -->




<P><FONT SIZE=3D2 FACE=3D"Arial">Here's a nice one&#8230;&#8230;</FONT>

</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">Running opatch 1.0.0.0.54, applying =

one-off patch to 9.2.0.6 on Sparc Solaris 5.9 64-bit.</FONT>


</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">In my environment, the 'ar' binary =

(which Opatch uses to replace objects in libraries) is in /usr/ccs/bin =
and as it happens, was not in the oracle users' default =
$PATH.</FONT></P>



<P><FONT SIZE=3D2 FACE=3D"Arial">Well, OPatch does NOT check if 'ar' is =

in it's path before proceeding.&nbsp; The result is, if 'ar' is NOT in =
the $PATH, OPatch overwrites the library being patched w/ a zero-length =
file!</FONT></P>



<P><FONT SIZE=3D2 FACE=3D"Arial">Yeah, not only does it not work, it =

cripples the $ORACLE_HOME!</FONT>


</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">Nice, eh?</FONT>

</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">Just a cautionary tale, in hopes others =

will avoid the pain I went through.</FONT>


</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">-Mark</FONT>

</P>




<P><FONT SIZE=3D2 FACE=3D"Arial">PS&nbsp; I have filed an enhancement =

request to have OPatch check for 'ar' before proceeding&#8230;.</FONT>


</P>




<P><B><FONT SIZE=3D2 FACE=3D"Century Gothic">--</FONT></B>




<BR><B><FONT SIZE=3D2 FACE=3D"Century Gothic">Mark J. Bobak</FONT></B>




<BR><B><FONT SIZE=3D2 FACE=3D"Century Gothic">Senior Oracle =

Architect</FONT></B>



<BR><B><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Century =

Gothic">P</FONT><FONT SIZE=3D2 FACE=3D"Century Gothic">ro</FONT><FONT =
COLOR=3D"#FF0000" SIZE=3D2 FACE=3D"Century Gothic">Q</FONT><FONT =
SIZE=3D2 FACE=3D"Century Gothic">uest Information &amp; =
Learning</FONT></B>


</P>




<P><FONT FACE=3D"Californian FB">&quot;There are 10 types of people in =

the world:&nbsp; Those who understand binary, and those who =
don't.&quot;</FONT>



<BR><FONT FACE=3D"Arial" SIZE=3D2 COLOR=3D"#000000"> &lt;&lt;Bobak, =

Mark.vcf&gt;&gt; </FONT>


</P>




</BODY>

</HTML>

------_=_NextPart_002_01C62B3F.80E829BE--

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

Received on Mon Feb 06 2006 - 11:18:03 CST