cu.xml mancante

User:

Ho un’application server Websphere 8.5 e, dopo aver effettuato il deploy di pacchetti EAR, all’avvio del pacchetto ottengo un errore simile a questo: [4/1/26 10:57:49:796 CEST] 000000f4 FileDocument  E   ADMR0104E: The system is unable to read document /opt/IBM/WebSphere85/AppServer/profiles/BEColl_AppSrv85_
01/config/temp/download/cells/SDACollBackEndCell/cus/STP_EAR/cver/BASE/cu.xml: java.io.IOException: No such file or directory.

Assistant:

L’errore indica che WebSphere sta cercando un file di configurazione temporaneo (cu.xml) nella directory config/temp/…, ma il file non esiste più oppure la directory non è stata creata correttamente durante il deploy.

Questo tipo di errore ADMR0104E è tipico in 3 casi:

• il deploy è stato interrotto o incompleto 
• la directory config/temp è corrotta o contiene riferimenti obsoleti 
• il nodo non ha sincronizzato correttamente (in ambiente ND)

Come risolvere (procedura consigliata)

1. Spegnere l’application server relativo al pacchetto EAR.
2. Cancellare tutte le directory temporanee di WebSphere:
   • profiles/<profile>/wstemp
   • profiles/<profile>/temp
   • profiles/<profile>/config/temp
   Sono cache: WebSphere le ricrea automaticamente al riavvio.
3. (Se ambiente ND) eseguire una sincronizzazione del nodo:
   • dalla console: System administration → Nodes → Synchronize
   • oppure via CLI: syncNode.sh <dmgr_host> <soap_port>
4. Rieseguire il deploy dell’EAR
   • Cancella l’applicazione 
   • Riaggiungi l’EAR 
   • Riesegui il deploy completo 
   • Avvia
5. Verificare permessi filesystem
   Assicurati che l’utente WebSphere (di solito wasuser) abbia:
   • permessi di lettura/scrittura su /opt/IBM/WebSphere85/AppServer/profiles/...
   • permessi su filesystem temporanei
6. Controllare che non ci siano riferimenti “custom” errati nella cartella cus/
   A volte customizations o estensioni creano riferimenti per risorse mancanti.

In breve

WebSphere sta cercando un file temporaneo che non dovrebbe essere richiesto all’avvio. Rimuovere cache/temp e ridistribuire l’EAR risolve quasi sempre.

Vuoi che ti indichi quali log guardare per verificare se il deploy è realmente completo?

User:

Come faccio ad individuare il profilo giusto ?

Assistant:

Il modo più rapido è controllare da dove parte il server e quale profilo lo contiene. Hai diverse opzioni.

1. Conoscere il profilo dal processo in esecuzione

Se l’application server è già avviato:

1. Trova il PID del server:ps -ef | grep java | grep WebSphere
2. Nel comando vedrai un parametro simile a:-Dwas.install.root=/opt/IBM/WebSphere85/AppServer -Dserver.root=/opt/IBM/WebSphere85/AppServer/profiles/BEColl_AppSrv85_01 Il percorso dopo profiles/ è il profilo corretto.

2. Verificare i profili installati

Elenca i profili disponibili:

cd /opt/IBM/WebSphere85/AppServer/bin
./manageprofiles.sh -listProfiles

Ti mostrerà nomi come:

• BEColl_AppSrv85_01 
• Dmgr01 
• AppSrv01

Identifichi il tuo cercando quello associato all’application server in errore.

3. Controllare i file di log

Nell’errore che hai mostrato c’è un indizio:

profiles/BEColl_AppSrv85_01/...

Quindi il profilo è quasi certamente BEColl_AppSrv85_01.

Puoi cercare nei log:

find /opt/IBM/WebSphere85/AppServer/profiles -name SystemOut.log

Aprendo il log del server che dà errore, vedrai nel percorso quale profilo lo contiene.

4. Guardare i file serverindex.xml

Ogni profilo ha un file che descrive i server al suo interno:

/opt/IBM/WebSphere85/AppServer/profiles/<profilo>/config/cells/*/nodes/*/serverindex.xml

Dentro trovi i nomi dei server:

<serverEntries serverName="STP_EAR" ... >

Se trovi il tuo server lì, hai trovato il profilo.

Metodo più semplice in assoluto

Esegui:

/opt/IBM/WebSphere85/AppServer/bin/manageprofiles.sh -listProfiles

e individua quello che contiene il server cercando nel suo percorso:

cd /opt/IBM/WebSphere85/AppServer/profiles/<profilo>/logs/

Vuoi indicarmi il nome esatto del server (ad es. server1, STP_EAR, ecc.) per identificare con precisione il profilo?