Wednesday, 13 November 2013

adoafmctl.sh: exiting with status 150|OPMN services not comming up exiting with status 150

Problem:

You are running adoacorectl.sh version 120.13
Starting OPMN managed OACORE OC4J instance  ...
adoacorectl.sh: exiting with status 150
adoacorectl.sh: check the logfile /data1/GRPDB/inst/apps/GRPDB_grpprdap/logs/appl/admin/log/adoacorectl.txt 
****************************************************
You are running adoafmctl.sh version 120.8
Starting OPMN managed OAFM OC4J instance  ...
adoafmctl.sh: exiting with status 150
Executing service control script:
/data1/GRPDB/inst/apps/GRPDB_grpprdap/admin/scripts/adoacorectl.sh start
script returned:
****************************************************
You are running adoacorectl.sh version 120.13
Starting OPMN managed OACORE OC4J instance  ...

adoacorectl.sh: exiting with status 150

Cause:
=====
When we start the services, a lock file will be generated for the process and this lock file will persist till the time services are up.

This is a “safety feature” within the lightweight (pure java) OC4J Java Messaging System (JMS) implementation. The OC4J Java Messaging System creates a lock file to constrain access to a specific persistent message store to the single OC4J instance that created it.

The persistence lock file captures information about the OC4J instance that owns or previously owned the persistence store and this information includes the IP address of the owning oc4j instance. During startup if the OC4J Java Messaging System (JMS) discovers that a persistence store it has been configured to use has a lock file that it doesn’t own it will abort the startup procedure to avoid data corruption.When we bring down the services, the lock file will be removed automatically.

Now  when the services are not brought down gracefully then in that case the lock file will be still present and this file will create problem when we try to bring up the environment. Because for system, the message store is owned by some other OC4J instance and so it won’t allow any other OC4J instance to start the service.


Solution (A):

How to troubleshoot status code 204  Issue for OC4J ?
1. First check startup log at $LOG_HOME/appl/admin/log/ adoacorectl.txt, adoafmctl.txt, adoaformsctl.txt
2.
Next check log at  $LOG_HOME/ ora/ 10.1.3/ opmn/ opmn.log

3.Later comes the Apache logs. Location is "$LOG_HOME/ora/10.1.3/Apache".
      The files are error_log and access_log, check the latest ones.

Solution to this  problem is to remove these lock files and start the service. Lock files will be present at the below locations.

In case of OACORE services, lock file will be present at $INST_TOP/ora/10.1.3/j2ee/oacore/persistence/oacore_default_group_1 directory.

Remove all the files under this directory and start the oacore service.

In case even the forms are not opening and giving the same error, then lock files for forms can be located at $INST_TOP/ora/10.1.3/j2ee/forms/persistence/forms_default_group_1 directory and all the files under this directory can be removed. Forms services will come up, once these lock files are removed.

To implement the solution, please execute the following steps:

If the problem is related to port issue, change the port in jms.xml. Otherwise, do the following for the lock file  issue.

  1. Remove the entire contents of the directory <oc4j-dir>/j2ee/home/persistence
  2. Start the oc4j using opmnctl startall
eg :

stop all R12 procs
  
rm -rf $ORA_CONFIG_HOME/10.1.3/j2ee/oacore/persistence/*
rm -rf $ORA_CONFIG_HOME/10.1.3/j2ee/oafm/persistence/*
rm -rf $ORA_CONFIG_HOME/10.1.3/j2ee/forms/persistence/*
  
start all service again 

References: 

Metalink note ID 372412.1

Metalink note ID  398973.1

No comments:

Post a Comment