![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Probleme beim Start oder Neustart des Anwendungsservers
Wenn der Serverprozess gar nicht oder mit Fehlern gestartet wird, können Ihnen die folgenden Artikel bei der Fehlerdiagnose helfen.
Installationsprogramm wird fehlerfrei ausgeführt, aber ein Anwendungsserver wird gar nicht oder mit Fehlern gestartet
- Suchen Sie in den Protokolldateien von Application
Server nach Hinweisen. Die Protokolldateien sind standardmäßig in den folgenden
Verzeichnissen gespeichert:
Profilstammverzeichnis/logs/Servername/SystemErr.log und SystemOut.log
Profilstammverzeichnis\logs\Servername\SystemErr.log und SystemOut.log
Profilstammverzeichnis/logs/Servername/SystemErr.log und SystemOut.log
Mit dem Befehl tail -f Profilstammverzeichnis/ logs/Servername/SystemOut.log kann der Fortschritt des Servers auf einfache Weise überwacht werden.
- Suchen Sie nach Fehlern oder Warnungen, die sich auf spezifische Ressourcen
des Moduls, wie z. B. Webmodule, Enterprise-Beans und Messaging-Ressourcen, beziehen. Wenn Sie Fehler finden, überprüfen Sie
die Konfigurationsdatei des Anwendungsservers auf die Konfigurationseinstellungen dieser Ressource. Starten Sie
den Server dann erneut, um zu erkennen, ob diese Komponente das Problem verursacht.
Überprüfen Sie in einer Basis- bzw. nicht verteilten Konfiguration auf Windows-Systemen in der Datei Profilstammverzeichnis\config\cells/ApplicationServerCell\nodes\Knotenname\servers\Servername\server.xml die XML-Tags für die Eigenschaften dieser Ressource. Ändern Sie den Wert für initialState von START in STOP.
Überprüfen Sie in einer Basis- bzw. nicht verteilten Konfiguration auf Windows-Systemen in der Datei Profilstammverzeichnis/config/cells/ApplicationServerCell/nodes/Knotenname/servers/Servername/server.xml, die XML-Tags für die Eigenschaften dieser Ressource. Ändern Sie den Wert für initialState von START in STOP.
- Suchen Sie alle Fehlernachrichten und Warnungen in der Nachrichtenreferenztabelle. Wählen Sie hierzu im Information Center die Ansicht Referenz aus und erweitern Sie in der Navigationsstruktur den Eintrag Nachrichten.
- Wenn Sie einen Anwendungsserver erstellt haben, müssen Sie die Knoten synchronisieren, bevor Sie die Konfigurationseinstellungen für den neuen Server speichern.
Synchronisieren Sie die Knoten nicht, wird der neue Server möglicherweise nicht gestartet.
- Klicken Sie auf der Seite "Anwendungsserver", auf der alle Anwendungsserver aufgelistet sind, auf Vorgaben.
- Wählen Sie die Option Änderungen mit Knoten synchronisieren aus, falls noch nicht geschehen.
- Klicken Sie auf Anwenden und dann auf Anwendungsserver, um zur Liste der Anwendungsserver zurückzukehren.
- Klicken Sie auf Speichern, um die Konfigurationseinstellungen für den neuen Server zu speichern.
- Wenn der Anwendungsserver zu einer Network Deployment-Konfiguration oder einer
Konfiguration mit mehreren Servern gehört, gehen Sie wie folgt vor:
Stellen Sie sicher, dass die beschriebenen Schritte für das Hinzufügen des Anwendungsservers zur Konfiguration ausgeführt wurden.
- Vergewissern Sie sich, dass die Konfiguration zwischen dem Deployment Manager und dem Knoten synchronisiert ist. Wenn die automatische Synchronisation aktiv ist, warten Sie, bis die Synchronisation abgeschlossen werden konnte. Fordern Sie bei Verwendung der manuellen Synchronisation eine Synchronisation für jeden Knoten im Cluster an.
Führen Sie vor dem Starten eines Anwendungsservers folgenden Schritt aus:
- Starten Sie den Deployment-Manager-Prozess mit dem folgenden Befehl:
Stammverzeichnis_des_Anwendungsservers/bin/startManager.sh
Stammverzeichnis_des_Anwendungsservers\bin\startManager.bat
- Binden Sie den Knoten, auf dem der Anwendungsserver ausgeführt wird, in den Deployment Manager ein. Dieser Schritt muss auch dann ausgeführt werden, wenn nur ein Knoten vorhanden ist oder wenn beide Prozesse auf demselben physischen Server ausgeführt werden.
- Vergewissern Sie sich, dass der Deployment Manager ausgeführt wird. Sie können auch den Befehl addNode nodename im Verzeichnis Profilstammverzeichnis/bin ausführen. Verwenden Sie auf Linux- oder UNIX-Systemen beispielsweise den folgenden Befehl, um den Anwendungsserver dem Deployment Manager hinzuzufügen:
addNode.sh localhost 8879 -includeapps -startingport 3333
Der Deployment Manager verwendet den Standard-SOAP-Port 8879. Beide Prozesse werden auf derselben Maschine ausgeführt. Alle im Anwendungsserver installierten Anwendungen (mit Ausnahme der Administrationskonsole, die eine Systemanwendung ist) werden im Deployment Manager installiert.
Der Parameter "startingport" verhindert das Problem koexistierender Node-Agent-Prozesse auf einer Maschine. Alle Ports für den Node-Agent-Prozess beginnen bei der Portnummer 3333. Mit dem Parameter "-portprops" können Sie spezielle Ports zuordnen.
Weitere Informationen finden Sie in der Beschreibung des Befehls "addNode".
- Starten Sie den Node-Manager-Prozess auf den Knoten mit den Anwendungsservern, die Sie ausführen möchten, mit dem Befehl Stammverzeichnis_des_Anwendungsservers/bin/startNode.sh bzw. Stammverzeichnis_des_Anwendungsserver\bin\startNode.bat.
- Starten Sie den Deployment-Manager-Prozess mit dem folgenden Befehl:
Führen Sie vor dem Starten von Anwendungsservern das Qshell-Script "startNode" aus, um den Node-Agent-Prozess in den Knoten, auf dem die zu startenden Anwendungsserver installiert sind, zu starten.
- Vergewissern Sie sich, dass der logische Name, der in der Konsole für Ihren Anwendungsserver angezeigt werden soll, keine ungültigen Zeichen wie die folgenden enthält: - / \ : * ? " < > > und vorangestellte oder nachfolgende Leerzeichen.
Sollte der Deployment Manager nach einer ansonsten erfolgreich verlaufenen Installation nicht starten, suchen Sie in den Dateien Profilstammverzeichnis/logs/Servername/SystemErr.log und SystemOut.log nach Nachrichten.
Sollte der Deployment Manager nach einer ansonsten erfolgreich verlaufenen Installation nicht starten, suchen Sie in den Dateien Profilstammverzeichnis/logs/Servername/SystemErr.log und SystemOut.log nach Nachrichten.
- Wenn Sie Apache Derby verwenden und den Fehler ERROR XSDB6: Another instance of Apache Derby might have already booted the database Datenbankname empfangen, wenn Sie den Anwendungsserver starten, finden Sie im Artikel Probleme beim Datenzugriff weitere Informationen.
Wenn Sie den Anwendungsserver unter einer anderen Benutzer-ID als Root ausführen, müssen Sie Folgendes sicherstellen:
- Der Benutzer ohne Root-Rechte hat Schreibzugriff auf das Verzeichnis Installationsstammverzeichnis/temp.
- Die JVM hat Schreibzugriff auf die Datei Stammverzeichnis_des_Anwendungsservers/config/plugin-cfg.xml.
- Der Benutzer hat Zugriff auf das Verzeichnis logs.
Wenn Sie ein anderes Benutzerprofil als QEJBSVR zur Ausführung eines Anwendungsservers verwenden, überprüfen Sie Folgendes:
- Für das Benutzerprofil wurde das Gruppenprofil QEJBSVR angegeben.
- QEJBSVR ist der Eigner aller Dateien und Verzeichnisse unter dem VerzeichnisProfilstammverzeichnis.
Sie können den folgenden Befehl in einer Qshell-Sitzung verwenden, um QEJBSVR als Eigner festzulegen:
chown -R QEJBSVR Profilstammverzeichnis
- Der Anwendungsserver wird möglicherweise nicht im Modus des eingeschränkten Betriebs gestartet. Ein Anwendungsserver kann so konfiguriert werden, dass er den Zugriff auf interne Serverklassen zulässt oder verweigert. Standardmäßig wird der Zugriff zugelassen. Ist der Zugriff eingeschränkt, treten beim Serverstart möglicherweise Fehler auf. Wenn der Anwendungsserver nicht im Modus des eingeschränkten Betriebs gestartet wird, müssen Sie den Zugriff auf interne Klassen in Zulassen ändern.
Nach dem Neustart eines Anwendungsservers kann in der Datei SystemOut.log eine Fehlernachricht enthalten sein
Die Socket-Bindung für Host Hostname und Port Portnummer ist fehlgeschlagen. Der Port ist möglicherweise schon im Gebrauch.
Diese Fehler kann auftreten, wenn das Netz langsam ist und der im Nachrichtentext angegebene Port mit dem Empfang einer Nachricht noch nicht fertig war, als die Anwendung gestoppt bzw. erneut gestartet wurde.
Überprüfen Sie den Portstatus, um sicherzustellen, dass der Fehler auf diese Ursache zurückzuführen ist.
Stellen Sie sicher, dass keine Ports derzeit Nachrichten empfangen. Verwenden Sie den folgenden Befehl:
netstat -a
Stellen Sie sicher, dass keine Ports derzeit Nachrichten empfangen. Verwenden Sie den folgenden CL-Befehl:
NETSTAT *CNN
- Starten Sie den Server erneut.
Ausnahmenachricht "DiscoveryService.sendQuery" in der FFDC-Protokolldatei
Wenn Sie einen Deployment Manager starten, versucht der Deployment Manager, alle konfigurierten Node Agents in seiner Zelle zu erkennen. Wenn der Deployment Manager die Node Agents in der Zelle nicht erkennt, schreibt er für jeden nicht erkannten Node Agent eine Ausnahme in die FFDC-Protokolldatei. Sie können diese Ausnahme ignorieren, wenn nicht von aktiven Node Agents ausgegangen wurde. Wenn die Node Agents hätten aktiv sein sollen, kann die FFDC-Protokolldatei weitere Informationen enthalten, die Ihnen helfen festzustellen, warum der Deployment Manager die Node Agents nicht erkennen kann, obwohl anzunehmen ist, dass die Node Agents aktiv sind.
![[IBM i]](../images/iseries.gif)
Nachdem WebSphere Application Server Version 8.5.0.1 angewendet wurde, kann unter IBM i kein Serverneustart ausgeführt werden
Wenn Server unter IBM i nicht erneut gestartet werden kann, nachdem Version 8.5.0.1 angewendet wurde, wird möglicherweise die folgende Fehlernachricht zurückgegeben: "CWWKE0044E: Es liegt keine Schreibberechtigung für das Serververzeichnis vor."
Dieser Fehler tritt unter IBM i nur dann auf, wenn der Server mit Betriebssystemintegration und unter dem Benutzer QEJBSVR gestartet wird.
Sie können diesen Fehler temporär beheben, indem Sie den Aufruf des Serverbefehls in ein Script einschließen, das den Inhalt des Verzeichnisses <Servername>>/workarea/.sCommandAuth löscht.