Kevin Kempf's Blog

April 14, 2010

Discoverer EUL exports fails on libpthread.so.0

Filed under: Discoverer, Linux — kkempf @ 8:49 am

The export fails

I noticed a cron job which ran a nightly export of the Discoverer End User Layer schema was failing recently, and upon investigation the exact error looked like this:

java: error while loading shared libraries: libpthread.so.0: cannot open shared object file: No such file or directory

To be precise, the exact point of failure is in the call to $DISCOVERER_HOME/bin/eulapi

What the script is, and why I run it

I don’t know how relevant any of this is to anyone anymore, as Discoverer use is declining, and the export is pretty much just insurance for me.  The main reason I ever started the job was during development/migration of all of our reports from 4i to 10g; it was a nice way to be able to quickly revert to “yesterday” without affecting the rest of 11i.   I run the job as a cron of a parameterized script on linux; which looks like this in the crontab:

# run a nightly export of the Discoverer EUL
0 21 * * * /scratch/oracle/dba/discoverer/exportEUL.sh -sid PROD -eulapi /u02/appprod/proddisco/bin > /dev/null

exportEUL.sh

#!/bin/ksh
##############################
# Oracle Discoverer EUL Export
##############################
# Run this script as a cron only from the discoverer node; it will fail elsewhere
# default EUL
EUL=eul_us
if [ $# -eq 0 ]
then
echo "Usage:  exportEUL.sh"
echo "    -sid      (DEV)                            Instance"
echo "    -eul      (eul_us)                         EUL name"
echo "    -eulapi   (/u02/appmis/misora/iAS10g/bin)  Path to eulapi binary"
echo
exit 1
fi
for parm in `echo $*`
do
if [ $1 = '-sid' ]
then
shift
SID=$1
elif [ $1 = '-eul' ]
then
shift
EUL=$1
elif [ $1 = '-eulapi' ]
then
shift
EULAPI=$1
fi
if [ $2 ]
then
shift
fi
done
# lower case SID
LOWERSID=`echo $SID|tr [A-Z] [a-z]`
PASSW=`cat /scratch/home/ora${LOWERSID}/.discoverer`
CONNECT=sysadmin/$PASSW\@${SID}
TODAY=`date +%d%m%y`
EXPORTFILE=/scratch/oracle/dba/discoverer/exp${SID}_${TODAY}.eex
LOGFILE=/scratch/oracle/dba/discoverer/exp${SID}_${TODAY}.log
${EULAPI}/eulapi -connect ${CONNECT} -apps_user -apps_responsibility "System Administrator" -eul ${EUL} -export ${EXPORTFILE} -all -log ${LOGFILE}
zip ${EXPORTFILE}.zip ${EXPORTFILE}
rm ${EXPORTFILE}
zip ${LOGFILE}.zip ${LOGFILE}
rm ${LOGFILE}
find /scratch/oracle/dba/discoverer/*PROD*.zip -mtime +31 -exec rm -rf {} \;
find /scratch/oracle/dba/discoverer/*DEV*.zip -mtime +7 -exec rm -rf {} \;

The Fix

I found this on MOS, in ID 729952.1.  Well most of this.  #4, below, was wrong in the document online as it implied applypreferences.sh was in $ORACLE_HOME/discoverer, but I added the full (and correct) path for clarity.  It’s about the cheesiest fix I’ve seen in awhile, but it works.  Anytime I’m asked to “pound out” a line of a delivered shell script, it feels wrong, but in the end, it’s no different than all the fixes you used to have to make after an autoconfig run to various 11i files which got messed up before the templates finally got in order.

  1. Navigate to:  $ORACLE_HOME/discoverer.
  2. Backup the discwb.sh environment script file.
  3. Remove “export LD_ASSUME_KERNEL=2.4.19” from the discwb.sh file.
  4. You can now execute:  $ORACLE_HOME/discoverer/util/applypreferences.sh

The Cause

Unknown, but my suspicion is that it was either an OS upgrade or a Discoverer CP patch.

Advertisements

Blog at WordPress.com.