Kevin Kempf's Blog

August 24, 2009

11i Stub Library: libc-2.1.3-stub.so (aka Concurrent Managers Won’t Start with GSM=Y) Finally Fixed!

Filed under: 11i, Cloning, Concurrent Managers, Linux, Oracle, Utilities — Tags: , — kkempf @ 10:06 am

I’ve been working this week on setting up my regression TEST environment for an upcoming cycle; among the patches I’m testing are ATG_PF_H RUP7, AD.I.7 and the latest autoconfig templates.  It never fails when I apply core framework technology: my 8.0.6 stub libraries get hosed.  By “getting hosed” I’m referring to various Signal 11 errors, or variants of these, which cause the concurrent managers to fail to start until you set GSM=N or fix it as I’ll detail further here.  But I got sick of applying 3830807 to fix it, and decided to dig deeper into the 8.0.6 homes…. here’s what I found….

As review, Developer 6i (Forms, Reports, CMs) in 11i is generally what people are talking about when they say $ORACLE_HOME or 8.0.6 Home on the application server.   The iAS_ORACLE_HOME is Application Server 9iR1 (technically 1.0.2.2.2 in my case) and runs Apache.

3830807 delivers 2 binaries and a shell script.  Basically the script goes out and fixes make files, if necessary, puts a few symbolic links in the directory, and lands the binaries in the 8.0.6 home under lib/stubs.

  • libc-2.1.3-stub.so ($8.0.6 Home/lib/stubs) needs to be 261328 bytes in size, and libc.so 71 bytes.  In my case, libc-2.1.3-stub.so was 131951 bytes and needed to be fixed.

First I had to understand what I was dealing with, and what caused it.  A quick scan of my environments showed all non-production environments had the wrong version, and they were all date stamped the date of the last clone.  It turns out that adcfgclone (adclone, autoclone, whichever you prefer) is the culprit.  But I’m on the latest everything as far as I know: ATG F RUP 6, ADI.7, TXK Autoconfig Templates T….

With help, I found that the setup_stubs.sh script in the $iAS Home (Apache Home, or $ORACLE_HOME/../iAS, generally, on the apps tier) was actually corrupting the libc-2.1.3-stubs.so file in the $8.0.6 Home/lib/stubs.  I could not figure out where the 131951 byte version of libc-2.1.3-stubs.so was even coming from, but there it was, sitting in the iAS Home/lib/stubs, dated June of 2001.  Wow!  That’s old! Another piece I was able to confirm: unless adadmin executable recompiles are forced, or a patch specifically calls for a recompile, this “bad” libc-2.1.3-stubs.so can sit there silently waiting to affect you later.  When I looked at all my cloned environments, they all had the “bad” version of the file, but because I hadn’t happened to manually force an adadmin executable relink (and why would I, under normal circumstances?) my concurrent managers and all other FND binaries still worked.

Now we’re getting somewhere… but I still don’t know one fundamental question: can I safely patch the iAS Home with a newer version of libc-2.1.3-stubs.so?

At this point, I turned to Oracle support..  It’s been there since… I’ll update this entry as I make progress.

Relevant Notes: 465629.1, 847775.1

Related Patch: 3830807

* edit* 9/2/09: still waiting on word from support…

* edit* 9/23/09: Support confirmed I can overwrite the $IAS_HOME/lib/stubs version (131951 byte) of the file libc-2.1.3-stubs.so with the (newer) version (261328 bytes) of the file from $8.0.6 Home/lib/stubs:

UPDATE
=======
Development confirm that you can safely copy the newer file over the older file.

QUESTION
=========
Can the older (131951 byte) version of libc-2.1.3.sub.so in the iAS home be overwritten by the one delivered with patch:3830807 (261328 bytes)?

ANSWER
========
Yes, based on reasearch this appears to be the intended situation. So please copy the newer file over the older file. This should then be a permanent fix for this problem.

Blog at WordPress.com.