Il server WebLogic non viene riavviato dopo un errore

Dopo un errore del nodo, l'avvio del server WebLogic non riesce.

Il log del servizio WebLogic contiene un messaggio di errore simile al seguente:

java.io.IOException: Error from fcntl() for file locking, Resource temporarily unavailable, errno=11

Causa 1: i server NFSv3 non includono una funzione di lock lease, pertanto gli stati di lock non vengono memorizzati e i lock non possono essere rilasciati dopo l'errore del nodo.

Soluzione 1: richiedere la rimozione dei blocchi di file. Per ulteriori informazioni, vedere Rimozione dei blocchi di file da un host non più disponibile.

Causa 2: a volte il servizio rpc-statd, necessario per il blocco NFSv3, si trova in uno stato non valido dopo l'errore del server. Ciò può essere verificato eseguendo un test di blocco di esempio utilizzando il modulo fcntl. Ad esempio:

$python3
>>> import fcntl
>>> f = open('/fss/path/testfile.txt', 'r') #Open an existing file as read mode (do not use 'w')
>>> fcntl.flock(f, fcntl.LOCK_EX | fcntl.LOCK_NB) #Throws "no lock available" error.
>>> exit()

Soluzione 2: riavviare il servizio rpc-statd.

1. Aprire una finestra di terminale sull'istanza e utilizzare i comandi seguenti come utente root:

   $sudo systemctl status rpc-statd 
   $sudo systemctl stop rpc-statd 
   $sudo systemctl start rpc-statd 
   $sudo systemctl status rpc-statd 

2. Verificare che la verifica del blocco di esempio fcntl venga completata senza errori.
3. Avviare il server WebLogic.

Causa 3: NFSv3 non tiene traccia dei proprietari del blocco. Pertanto, NFS conserva il blocco a tempo indeterminato in caso di errore del proprietario del blocco. Dopo un errore del nodo, un tentativo di riavvio WebLogic non può acquisire un blocco.

Soluzione 3: si tratta di una limitazione generale di NFSv3. La documentazione di WebLogic fornisce considerazioni immediate sulla mitigazione e sulla progettazione a lungo termine. Per maggiori informazioni, vedere Verifying Server Restart Behavior.