Troubleshooting
Problem
After applying a fix or fix pack with the Update Installer, servers (Dmgr, NodeAgent, and AppServers) may fail to start. The SystemOut.log will not even be generated to indicate why. The startServer.log shows: ADMU3011E: Server launched but failed initialization. startServer.log, SystemOut.log(or job log in z/OS® ) and other log files under /home/dwhare/WebSphere61/profiles/Dmgr01/logs/dmgr should contain failure information.
Symptom
ADMU3011E: Server launched but failed initialization. startServer.log, SystemOut.log(or job log in z/OS® ) and other log files under /home/dwhare/WebSphere61/profiles/Dmgr01/logs/dmgr should contain failure information.
!ENTRY org.eclipse.osgi 2006-08-24 09:04:14.597
!MESSAGE Error reading configuration: /home/dwhare/WebSphere61/profiles/Dmgr01/configuration/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)
!STACK 0
java.io.FileNotFoundException: /home/dwhare/WebSphere61/profiles/Dmgr01/configuration/org.eclipse.osgi/.manager/.fileTableLock (Permission denied)
at java.io.FileOutputStream.openAppend(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:203)
at org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio.lock(Locker_JavaNio.java:34)
at org.eclipse.core.runtime.adaptor.FileManager.lock(FileManager.java:361)
at org.eclipse.core.runtime.adaptor.FileManager.open(FileManager.java:658)
at ...
Cause
The problem is caused by applying a fix or fix pack as root when the IBM® WebSphere® Application Server environment is set up to run as a non-root user.
The Information Center says:
For existing installations, the root or non-root installer who owns the currently installed files is the only user who can perform subsequent installation or removal operations on that installation.
The reason the server fails to start is the OSGI cache was not updated after applying the fix pack because of a permission's issue. To verify this, check the <WAS_PROFILE_HOME>/configuration/ directory for a log file with a string of numbers as the filename.
Resolving The Problem
To resolve this problem:
1) Stop all remaining Application Server processes if any
2) Change the file permission's on the entire WebSphere install back to the non-root user
3) Run <WAS_HOME>/profiles/<profile>/bin/osgiCfgInit.sh
4) Start the server
The osgiCfgInit command updates the contents of subdirectories in <WAS_HOME>/configuration/. This directory is used for caching data in the jars in <WAS_HOME>/plugins/.
When the data in the jar files is updated (when a service pack is installed, for example), the caching data needs to be updated. The updating of the cache is supposed to happen the first time a command is executed in a profile after a service pack has been installed. (for example, the startServer.sh command). However, if there is an exception, like one of the above, then the cache will not get updated so we need to run it manually.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21244631