- Issue
Earlier user have started/stopped the opmn process as an incorrect user (such as root) but are now logged in as the unix user that owns the Application Server installation. The AS unix owner then experiences permission related errors communicating with the root initiated OPMN process. He will not be able to start/shutdown the opmn related processes.
- Implementation
ØFirst check the ownership of the running "opmn -d" processes using below command:
$ ps -ef|grep 'opmn -d'|grep -v 'grep'
root 31011 1 0
root 31012 31011 0
ØLog in to the UNIX account that owns the current "opmn -d" processes (this may require root privileges).
ØUse "opmnctl stopall" to stop the opmn daemon and all processes
ØUse "ps -ef|grep 'opmn -d'|grep -v 'grep'" to confirm the two "opmn -d" processes have been terminated.If not terminated - use "kill -9
ØReview the PID column from the "opmnctl status -l" and confirm that each process has been stopped.If not stopped simialrly use "kill -9
ØFor the directory of each OC4J instance that exists below $ORACLE_HOME/j2ee,
rename the "persistence" directory to "persistence.old"
ØOr else an alternative to earlier step delete .lock files in the persistence folder. The owner
should be the user with which the opmn was started/shutdown last time [like root in our case] . (again, this may need root privileges)
ØConfirm if any files under the $ORACLE_HOME have been created under the incorrect unix account with below command
$ find $ORACLE_HOME -user root –print
ØWith the exception of files below the $ORACLE_HOME/Apache/Apache/bin directory,use "chown" to reset the owner and group of each files that has changed.
ØLog out from the incorrect UNIX account and log back in as the UNIX user owning the AS installation.
ØStart opmn and desired managed processes.Should work fine.