OPMN timeout killing Configuration Assistants

Question

Hello,
I am just trying to install a basic 10g AS (9.0.4) J2EE installation without Web Cache or OID/SSO.
I have configured the Red Hat 2.1 according to the Install Guide, I have all the patches, memory, and /etc/hosts setup.
Everything runs fine until I get to the Configuration Assistant section.
The Java Security Configuration Assistant Fails and subsequent attempts to re-run it also fails.
Although I see opmn processes running in the background, my initial suspicion is they are somehow messed up because of the timeout I get.
Attempts to run the other assistants after the Java Security Assistant also fail (probably because of OPMN not starting).
The jaznca.log shows the following:
$ more jaznca.log
Oracle JAAS [Sun Jan 25 11:53:26 EST 2004]: exception: null
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at oracle.security.jazn.util.JAZNInstallHelper.resync(Unknown Source)
at oracle.security.jazn.util.JAZNInstallHelper.setCredentials(Unknown Source)
at oracle.security.jazn.util.JAZNInstallHelper.main(Unknown Source)
Caused by: oracle.ias.sysmgmt.exception.TaskException: TaskMaster initialization failed.
Root Cause: Subscription request timed out after 120000 millseconds. Possible causes: OPMN may not be runni
ng, you may have an OPMN running in an alternate ORACLE_HOME using duplicate port values, or OPMN may be mis
configured.
Resolution: check the system configuration and make sure that the client can access the repository database.
at oracle.ias.sysmgmt.task.TaskMaster.sysInit(Unknown Source)
at oracle.ias.sysmgmt.task.TaskMaster.sysInit(Unknown Source)
at oracle.ias.sysmgmt.task.InstanceManager.sysInit(Unknown Source)
at oracle.ias.sysmgmt.task.InstanceManager.init(Unknown Source)
at oracle.ias.sysmgmt.EntryPoint.init(Unknown Source)
at oracle.security.jazn.smi.DcmUtil.resyncInstance(Unknown Source)
... 7 more
$
The opmn.log is empty.
These are the ons and ipm logs:
$ more ons.log
04/01/25 11:49:15 [4] ONS server initiated
$ more ipm.log
04/01/25 11:49:15 [4] Create pm state directory: /u01/app/oracle/product/9.0.4mt1/opmn/logs/states
04/01/25 11:49:15 [4] PM state file does not exist: /u01/app/oracle/product/9.0.4mt1/opmn/logs/states/.opmndat
04/01/25 11:49:15 [4] OPMN server ready. Request handling enabled.
$
Later attempts just to start opmn with opmnctl startall fail with only starting 1 of 2 processes. The OHS starts, but the default OC4J home instance fails.
Any ideas? This shouldn't be this difficult. The only potentially flakey issue is I have a 2.6 GHz Celeron processor instead of Pentium, but I have found no docs indicating that's a problem.
Thanks in advance!
Mike

Answer 1

Section 4.8 The /etc/hosts File of the HP/Linux doc states that:
The /etc/hosts file should use the following format:
ip_address fully_qualified_hostname short_hostname
because the installer reads that format to "construct the location of the default Identity Management realm". Basically it is used for OID and SSO setup.
The doc later mentions that you can temporarily set the /etc/hosts the purposes of the install or pass the fully qualified domain name as an OUI_HOSTNAME parameter.
So, technically speaking, this isn't as much of a hard requirment as in 9.0.2, but the software still wants the same information. Setting up the /etc/hosts in that format seems to be the easiest way to provide the info from an Oracle standpoint.
Under 9.0.2 this requirement was a big problem on existing machines. Any backport or way on 9.0.2 to "trick" the installer into running without permanently changing the name? Could you just temporarily change these values on a standalone J2EE + Web Cache install (without infrastructure)?