WebLogic Server wird nach einem Fehler nicht neu gestartet

Nach einem Knotenfehler kann WebLogic Server nicht gestartet werden.

Das WebLogic-Servicelog enthält eine Fehlermeldung wie die Folgende:

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

Ursache 1: NFSv3-Server enthalten kein Lock Leasing-Feature. Daher werden keine Sperrstatus gespeichert, und Sperren können nach dem Knotenfehler nicht freigegeben werden.

Lösung 1: Beantragen Sie das Entfernen von Dateisperren. Weitere Informationen finden Sie unter Dateisperren von einem Host entfernen, der nicht mehr verfügbar ist.

Ursache 2: Manchmal befindet sich der rpc-statd-Service, der für die Sperre von NFSv3 erforderlich ist, nach dem Serverfehler in einem fehlerhaften Zustand. Dies kann überprüft werden, indem ein Beispielsperrtest mit dem Modul fcntl ausgeführt wird. Beispiel:

$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()

Lösung 2: Starten Sie den rpc-statd-Service neu.

1. Öffnen Sie ein Terminalfenster auf der Instanz, und verwenden Sie die folgenden Befehle als Root-Benutzer.

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

2. Prüfen Sie, ob der fcntl-Beispielsperrtest ohne Fehler abgeschlossen wird.
3. Starten Sie den WebLogic-Server.

Ursache 3: NFSv3 verfolgt keine Sperreneigentümer. NFS hält die Sperre also unbegrenzt, wenn ein Sperreigentümer ausfällt. Nach einem Knotenfehler kann ein Neustartversuch des Typs WebLogic keine Sperre anfordern.

Lösung 3: Dies ist eine allgemeine Einschränkung unter NFSv3. In der Dokumentation von WebLogic sind sofortige Minderungs- und langfristige Designaspekte enthalten. Weitere Informationen finden Sie im Abschnitt Verifying Server Restart Behavior.