1

ADMU3011E: El servidor no arranca después de aplicar un FixPack

herramientaDespués de instalar un FixPack con el UpdateInstaller es posible que los servidores no arranquen.

Esto puede sucederle también al Dmgr y a los nodos.

Si revisamos el SystemOut.log no encontramos trazas significativas, pero si revisamos el StartServer.log encontramos un error como este:

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 ...

La causa de estos fallos en el arranque es la instalación de el FixPack con el usuario root cuando la instalación principal de WebSphere está hecha con un usuario distinto.

Buscando en el Information Center de IBM encontramos la explicación:

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.

La caché OSGI no se actualiza después de la instalación del FixPack por motivos de permisos.

La solución es sencilla:

  1. Parar todos los procesos de Servidores de Aplicaciones que sigan corriendo en la máquina.
  2. Cambiar el propietario de la instalación de WebSphere al usuario original de nuevo.
  3. Ejecutar el script <Ruta_instalación_WAS>/profiles/<perfíl>/bin/osgiCfgInit.sh
  4. Arrancar el servidor de aplicaciones de nuevo.

Lo que hace el script del punto 3 es actualizar el contenido de todos los subdirectorios de <Ruta_instalación_WAS>/configuration/, que es el directorio que se usa para cachear datos en los jars en <Ruta_instalación_WAS>/plugins/.

Cada vez que se actualicen datos en los jars (como pasa en la instalación de los FixPacks, por ejemplo), la caché tiene que actualizarse también. Este cacheo se produce la primera vez que se ejecuta un comando después de haber instalado un FixPack (un startServer, por ejemplo). En caso de que se produzca una excepción, la caché no se actualiza y hay que hacerlo manualmente.

One Comment

  1. Thank you for posting it, it helped us to solve a similar problem. In our case, we have WAS ND and a lot of different servers running on it. Each server runs under another user and, in this case, we had to correct the permissions under
    ///configuration
    for each server. But you hint send us to the correct place. Thank you again!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *