Lade...
 

MorphIT Fehlerdiagnose

Fehlerdiagnose unter MorphIT

Dieser Artikel stellt einen Leitfaden dar, um Fehler in MorphIT zu erkennen und zu beheben. 

 

Seite nicht erreichbar / Server antwortet nicht

Mögliche Ursachen:

Server kommt nicht aus dem Wartungsmodus raus

Mögliche Ursachen:

Lösungen:

Falls der Server im Testmodus ist, dann sollte die Admin-Konsole im status-Befehl in dem Abschnitt == Server == den Eintrag test mode: enabled haben. In dem Fall lässt sich der Testmodus einfach durch den Befehl test_mode disable über die Admin-Konsole wieder deaktivieren. 

Server startet nicht

Mögliche Ursachen:

  • NodeJS-Abhängigkeiten sind nicht up-to-date
  • Syntaxfehler in config.js
  • Einer der verwendeten Ports ist bereits von einem anderen Programm
  • Der Server wurde mehrfach gestartet oder ein früherer Server-Prozess hat sich nicht korrekt beendet
  • Der Dienst ist nach einem Neustart noch nicht gestartet, da er verzögert startet
  • Der Dienst ist falsch eingerichtet, weil sich Pfade seit der Installation geändert haben

Lösungen:

Sollte sich der Server nicht starten lassen, weil es sich sofort wieder beendet, dann kann die Fehlerursache dem Server-Log (Konsolenausgabe) entnommen werden. Startet der Server als Dienst, wird das Server-Log normaler Weise nach .../WebService/morphIT/logs/server.log geschrieben. 

Die Datei .../WebService/morphIT/custom/config.js muss eine gültige JavaScript-Datei sein. Ein Syntaxfehler in der Datei führt dazu, dass der Server nicht startet. In dem Fall enthält das Log eine entsprechende Fehlermeldung.

Um die NodeJS-Abhängikeiten upzudaten, muss nur das Script .../WebService/morphIT/setup_dependencies.bat ausgeführt werden. (Internetverbindung nötig)

Sollte ein verwendeter Port bereits in Benutztung sein, dann sollte dies auch so im Server-Log vermerkt sein. Hier hilft nur, in der .../WebService/morphIT/custom/config.js andere Ports einzurichten, oder die störende Anwendung zu beenden.

Sollte sich ein führerer Server-Prozess nicht vollständig beendet haben, dann kann dieser über den Task-Manager manuell beendet werden. Prozessname: node.exe

Falls der Server als Dienst (Name: ClassiX Web-Server, ID: cxserver) eingerichtet ist, ist dieser Dienst möglicher Weise noch nicht gestartet. Nach einem Neustart ist dies normal, denn der Dienst startet verzögert. Der Dienst kann in der Dienste-Verwaltung (services.msc) manuell gestartet werden. Sollte dies fehlschlagen, obwohl sich der Server manuell starten lässt (.../WebService/morphIT/start_server.bat), dann ist der Dienst möglicher Weise falsch eingerichtet. In der Ereignisanzeige von Windows sollten sich dann Fehlermeldungen von nssm (unserem Dienstprozess) finden lassen, die beschreiben, warum sich der Dienst nicht starten ließ. Das Problem lässt sich am leichtesten dadurch lösen, dass der Dienst entfernt und wieder installiert wird. Hierzu müssen die Scripte .../WebService/morphIT/uninstall.bat & .../WebService/morphIT/install_service.bat mit Administartorrechten gestartet werden.

 

Client kommt nicht aus der Warteschlange raus

Der Server ist gestartet und der Client kann sich mit dem Server verbinden und wird in die Warteschlange für eine ClassiX-Instanz eingereiht, danach passiert aber nichts mehr.

Mögliche Ursachen:

Lösungen:

Die Ursache für dieses Problem lässt sich am einfachsten mit der Admin-Konsole feststellen. Der status-Befehl gibt Aufschluss über den aktuellen Zustand des Servers.

In dem Abschnitt === Launch Strategy === sollte nach einem roten Eintrag ausschau gehalten werden. Ist der Status disabled, dann ist der Server nicht entsprechend konfiguriert, um selbstständig ClassiX-Instanzen nachzustarten. In der .../Webservice/morphIT/custom/config.js muss hierzu launch_strategy.enabled auf true gesetzt werden.
Sollte der Eintrag reserve target auf stehen, dann muss der Konfigurationswert launch_strategy.min_free_instances auf mindestens gesetzt werden, da ansonsten keine Instanzen vorgehalten werden.
Falls unter licenses der Eintrag  depleted steht, dann sind die ClassiX-Lizenzen aufgebraucht und es können deshalb keine neuen Instanzen mehr nachgestartet werden.
Steht unter launchers der Eintrag depleted, dann ist kein Launcher verbunden, oder die verbundenen Launcher sind bereits am Limit der zu startenden Instanzen. Falls kein Launcher verbunden ist, dann steht in dem Abschnitt === Launcher ===der Eintrag connected: 0. In dem Fall kann es sein, dass:

Sollte ein Launcher verbunden sein und die Launcher-Kapazitäten erschöpft, dann kann im Abschnitt === Launcher === für jeden einzelnen Launcher kontrolliert werden, wie viele Instanzen er starten kann und wie viele bereits gestartet wurden. Die maximale Anzahl an zu startenden Instanzen kann für jeden Launcher in der Datei .../Webservice/launcher/custom/launcher.js über den Schlüssel max_instances (Default: 4) festgelegt werden. Nachdem die Konfiguration angepasst wurde, reicht es, den Launcher-Dienst (Name: ClassiX Launcher, ID: cxlauncher) neu zu starten. Der Server muss hierzu nicht neu gestartet werden bereits gestartete Instanzen werden dadurch nicht beendet. Der Server wird durch einen Launcher-Neustart nicht beeinträchtigt.

 

Client kann sich nicht an interaktives ClassiX binden

Der Server ist gestartet, eine interaktiv gestartete ClassiX-Instanz ist mit dem Server verbunden (durch Admin-Konsole verifiziert), aber MorphIT kann sich nicht mit der Instanz verbinden.

Ursachen:

  • Verbindung zu interaktivem ClasisX nicht konfiguriert

Lösungen:

In der .../Webservice/morphIT/config.js ist der Schlüssel ws.classix.interactive.connect_to_morphit standardmäßig false, da dies hauptsächlich zur Entwicklung von MorphIT benötigt wird und im Produktivbetrieb deaktiviert sein sollte. In der .../Webservice/morphIT/custom/config.js muss dieser Wert mit true überschrieben werden, damit der Server eine Verbindung zwischen interaktivem ClassiX und MorphIT-Client erlaubt. Auf die Verwendung von nativen WebWidgets hat diese Option keinen Einfluss.

 

 

Client zeigt Schrift-Icons nicht oder nicht richtig an

Icons Werden Nicht Dargestellt

Mögliche Ursache:

  • In den Sicherheitsbestimmungen des Browser ist der Schriftartendownload deaktiviert.

Lösung:

  • Internet Explorer:
    Internetoptionen -> Sicherheit -> Internet -> Stufe anpassen
    In den Einstellungen Donwloads suchen und Schriftartendownload aktivieren.
    Anschließend die Seite neu laden.

Kontext IE Internetoptionen Sicherheit IE Stufe Anpassen Einstellungen IE

 

Client zeigt Bilder nicht an

Im Client werden keine Bilder angezeigt, oder einige Bilder nicht angezeigt. 

Ursachen:

  • Das Bild existiert einfach nicht
  • Die Asset-Konfiguration des Servers ist nicht vollständig
  • Launcher für Remote-Assets nicht gestartet
  • Die Konfigruation des Remoate-Assets-Launchers passt nicht zur Serverkonfiguration

Lösungen:

Falls das Bild einfach nicht existiert, dann wird es auch dann nicht angezeigt werden, wenn die Anwendung nativ geöffnet wird.

Falls das Bild nativ angezeigt wird, dann kann es daran liegen, dass die Asset-Konfiguraiton nicht vollständig ist. Um zu verifizieren, dass dies das Problem verursacht, sollte der Entwickler-Tab in MorphIT geöffnet werden (F12) und dann mit offenem Netzwerk-Tab die Seite nochmal öffnen, auf der das Bild fehlt. Falls in den geloggten HTTP-Anfragen eine Anfrage mit dem Pfad .../missing_path_map_entry auftaucht, dann beschwert sich der ClassiX-Prozess, dass der MorphIT-Server für den angefragten Bildpfad kein Pfad-Mapping definiert hat.
ClassiX benötigt, um einen Pfad, wie Y:\ClassiX\Evaluate\icons\test.png in /public/assets/images/test.png zu übersetzen die Information vom MorphIT-Server, welche lokalen Pfade in welche Web-Pfade übersetzt werden sollen und diese Information muss hier für die den gesuchten Pfad nachgeholt werden.

Der gesuchte Pfad wird von ClassiX als Warnung ins Log geschrieben in der Form:
No matching entry in path map found for asset path: "c:\classix\cyberenterprise_000005\icons\cx_keyword.png"

 

Falls die vom Browser angefragte Bild-URL sinnvoll aussieht, aber kein Bild geladen wird, und der Server für Remote-Assets konfiguriert wurde, dann kann der Fehler einfach daran liegen, dass der dafür zuständige Launcher nicht gestartet wurde, oder der host in der Pfadkonfiguration einen Tippfehler enthält. In diesem Fall antwortet der Server mit einer HTTP 503 Antwort. Und wenn man die URL manuell im Browser aufruft, oder sich im Netzwerk-Tab die Antwort anguckt, dann sieht man folgende vom Server generierte Antwort, die auch ausgibt, für welchen host der Launcher fehlt:

No launcher available for host #host# to serve this request.

Sollte der Launcher gestartet sein, dann muss geprüft werden, ob sich dieser auch mit dem Server verbunden hat (status Befehl in der Admin-Konsole) und falls nicht, dann sollte wie hier vorgegangen werden.

 

Sollte der MorphIT-Server Remote-Assets verwenden und anstatt der 503-Fehlermeldung vom Server wird das Bild einfach nicht geladen (Im Netzwerktab steht dann Status: Request pending), dann ist der Launcher zwar verbunden, kann die Datei aber nicht an den Server übertragen. Das wird vor allem dadurch verursacht, dass port in der config.js des Launchers nicht mit dem port der config.js des Servers übereinstimmt, denn die Anfrage eine Datei zu senden, stellt der Server über die Websocket-Verbindung, die über den ws.launcher.port läuft, aber die Datei selbst wird über einen HTTP-Put-Request vom Launcher an den Server übertragen und dieser wird auf dem unter port konfigurierten Port gestartet. Sollte dies das Problem sein, dann wird der Launcher auf Fehlermeldungen in der Konsole anzeigen, sobald die Bilder angefragt werden.

Client zeigt bei Fehlermeldung keine Fehlerdetails

Tritt ein Fehler im InstantView-Code auf, dann wird im MorphIT-Client zwar die Fehlermeldung gezeigt, es wird aber keine Codezeile angezeigt und kein Callstack. Auch die Buttons "Ja" (für weitere Details) wird nicht angezeigt.

Ursachen:

Lösung:

Dies ist so gewollt. Vom Launcher gestartete ClassiX-Instanzen sollen aus Sicherheitsgründen keine internen Informationen (wie einen Callstack) in einer Fehlermeldung an einen MorphIT-Client rausgeben. Dieser Mechanismus greift nicht für interaktiv gestartete ClassiX-Instanzen. 

Für die Fehlersuche sollte also entweder das Log ausgewertet werden oder der Fehler mit einer interaktiv gestarteten Instanz reproduziert werden.

Natives WebWidget zeigt sich nicht

Beim Öffnen des WebWidgets zeigt sich zwar der MorphIT-Hintergrund, aber nicht das WebWidget

Ursachen:

  • WebWidget-Port ist blockiert
  • Fehler im WebWidget-Code
  • Fehler im MorphIT-Code
  • ClassiX antwortet nicht

Lösungen:

Bei allen möglichen Fehlerursachen hilft ein Blick in die Entwickler-Konsole des Browsers (F12). Im Internet-Explorer muss die Seite nach dem Öffnen der Konsole neu geladen werden, damit etwaige Fehlermeldungen angezeigt werden. Sollte die Konsole eine Fehlermeldung enthalten, dann sollte sich aus der Meldung herleiten lassen, welcher der ersten drei Punkte zutrifft.

Steht in der Konsole keine Fehlermeldung, dann kann es sein, dass ClassiX nicht auf die Nachrichten des WebWidgets reagiert (möglicher Weise nicht implementiert). Hierzu muss man die einzelnen Nachrichten-Frames des geöffneten Websocktes untersuchen und mit der dem Protokoll des WebWidgets abgleichen. Chrome bietet diese Möglichkeit direkt an, für Firefox gibt es die Erweiterung: WebSocket Monitor.

 

Launcher startet nicht

Mögliche Ursachen:

  • NodeJS-Abhängigkeiten sind nicht up-to-date
  • Syntaxfehler in Konfigurationsdateien
  • Startbefehl nicht definiert
  • Der Dienst ist falsch eingerichtet, weil sich Pfade seit der Installation geändert haben

Lösungen:

Sollte sich der Launcher nicht starten lassen, weil es sich sofort wieder beendet, dann kann die Fehlerursache dem Launcher-Log (Konsolenausgabe) entnommen werden. Startet der Launcher als Dienst, wird das Launcher-Log normaler Weise nach .../Webservice/launcher/logs/launcher.log geschrieben. 

Um die NodeJS-Abhängikeiten upzudaten, muss nur das Script .../Webservice/launcher/setup_dependencies.bat ausgeführt werden. (Internetverbindung nötig)

Die Konfigurationsdateien .../Webservice/launcher/config/custom/launch.js .../Webservice/launcher/config/custom/launcher.js müssen gültige JavaScript-Dateien sein. Ein Syntaxfehler führt dazu, dass der Launcher nicht starten kann. Solch ein Fehler wird entsprechend im Log vermerkt.

In der Konfigurationsdatei .../Webservice/launcher/config/custom/launch.js muss ein Feld cmd definieren, welches den Startbefehl angibt (z.B Pfad zu Batch-Datei), mit welchem eine Instanz gestartet werden kann. Fehlt dieser Eintrag, dann startet der Launcher ebenfalls nicht. Der Fehler wird im Log vermerkt.

Falls der Launcher als Dienst (Name: ClassiX Launcher, ID: cxlauncher) eingerichtet ist, ist dieser Dienst möglicher Weise noch nicht gestartet. Nach einem Neustart ist dies normal, denn der Dienst startet verzögert. Der Dienst kann in der Dienste-Verwaltung (services.msc) manuell gestartet werden. Sollte dies fehlschlagen, obwohl sich der Launcher manuell starten lässt (.../Webservice/launcher/start_launcher.bat), dann ist der Dienst möglicher Weise falsch eingerichtet. In der Ereignisanzeige von Windows sollten sich dann Fehlermeldungen von nssm (unserem Dienstprozess) finden lassen, die beschreiben, warum sich der Dienst nicht starten ließ. Das Problem lässt sich am leichtesten dadurch lösen, dass der Dienst entfernt und wieder installiert wird. Hierzu müssen die Scripte .../Webservice/launcher/uninstall.bat & .../Webservice/launcher/install_service.bat mit Administartorrechten gestartet werden.

 

Launcher kann sich nicht zum Server verbinden

Der Launcher lässt sich zwar starten, in dessen Log (Konsolenausgabe) sieht man aber nur, dass die Verbindung zum Server fehlschlägt

Mögliche Ursachen:

Lösungen:

Beim Start gibt der Server im Server-Log (Konsole oder unter .../WebService/morphIT/logs/server.log) die Verbindungsinformationen aus. Dort steht in etwa folgende Zeile: Launchers should connect to   ws://localhost:8081/morphit/launcher

Falls an der Serverkonfiguration nichts diesbezüglich angepasst wurde, dann ist der Launcher von vornherein korrekt konfiguriert (falls Server und Launcher auf der gleichen Maschine laufen). Die Konfiguration des Launchers wird zusammengesetzt aus der .../Webservice/launcher/config/launcher.js und deren Werte können in der .../Webservice/launcher/config/custom/launcher.js überschrieben werden. Die korrekte Konfiguration kann wie folgt aus dem obigen Verbindungsstring hergeleitet werden:

Beginnt der String mit wss://, dann ist ssl:true ansonsten (ws://ssl:false.
host muss auf den Hostnamen des Rechners gesetzt werden, auf dem der Server läuft (Default: "localhost").
port ist die Zahl, die im Verbindungsstring auf den Hostnamen folgt (nach dem Doppelpunkt) (Hier: 8081).
endpoint ist der Rest des Verbindungsstrings (Hier: "/morphit/launcher")

Sollten Launcher und Server auf unterschiedlichen Maschinen laufen, dann kann die Firewall den Aufbau der Verbindung zusätzlich verhindern.

 

Launcher kann ClassiX-Instanzen nicht starten

Der Launcher ist mit dem Server verbunden, aber der Start einer Instanz schlägt fehl. Im Server-Log steht kein Verbindungsversuch einer ClassiX-Instanz.

Ursachen:

Lösungen:

Zunächst muss sichergestellt werden, dass sich die ClassiX-Instanz über den Launcher-Befehl (cmd aus .../WebService/launcher/config/custom/launch.js) regulär starten lässt (über die CMD).

In cmd kann auch eine Dateiumleitung angegeben werden. So kann über start_classix.bat > launch.log die Konsolenausgabe der Start-Batch zur Fehlersuche in eine Datei umgeleitet werden. Dies ist hilfreich, um Probleme zu untersuchen, die nur beim Start über den Launcher auftreten. Dabei kann der Zugriff auf Netzlaufwerke und Benutzerressourcen zu Problemen führen, denn der Launcher läuft normaler Weise als Dienstprozess und unter einem anderen Nutzer mit anderen Rechten und vermutlich ohne eingebundene Netzlaufwerke. Die gestarteten Unterprozesse laufen unter dem gleichen Benutzer und unterliegen damit auch den gleichen Einschränkungen.

Sollte sich ClassiX zwar starten lassen, sich aber direkt beim wieder beenden, sollte das entsprechende ClassiX-Logfile nach dem dazugehörigen Fehler durchsucht werden.

Server weist neu gestartete ClassiX-Instanzen ab

Der Launcher ist mit dem Server verbunden und der Server startet über den Launcher neue Instanzen, diese werden aber vom Server abgewiesen, sobald sie die Verbindung zum Server aufbauen.

Ursachen:

Lösung:
Falls es nicht an inkompatiblen Dlls liegt und OpenMorphITConnection nicht manuell mit falschen Parametern aufgerufen wurde oder die dafür verwendeten Umgebungsvariablen (CX_MORPHIT_...) überschrieben wurden, dann sollte die Verbindung problemlos aufgebaut werden können.

 

Fehlermeldung: Launched process terminated after only ... ms

Nachdem der Server eine neue Instanz über einen Launcher startet, taucht diese Fehlermeldung im Server-Log und Launcher-Log auf, obwohl die ClassiX-Instanz korrekt gestartet wurde und eine Verbindung möglich ist.

Ursachen:

  • Falsch konfigurierte Batch-Datei

Lösungen:

Wie in der Fehlermeldung beschrieben ist die Ursache für diese Meldung eine falsch konfigurierte Start-Batch-Datei. Hierdurch geht die Verbindung zwischen der ClassiX-Instanz verloren, was dazu führt, dass der Launcher nicht weiß, wie viele Instanzen wirklich gestartet sind (max_instances wird umgangen) und außerdem kann der Launcher eine nicht reagierende ClassiX-Instanz nicht mehr manuell beenden. Das Problem lässt sich auch über die Admin-Konsole diagnostizieren, denn dort sieht man im status zwar, dass ClassiX-Instanzen gestartet sind und in der ClassiX-Instanz steht auch von welchem Launcher sie gestartet wurde, beim betroffenen Launcher selbst steht dann aber, dass er keine Instanzen gestartet hat.

Der Launcher prüft in regelmäßigen Abständen, welche seiner gestarteten Prozesse noch laufen und weiß so, wie viele Instanzen noch gestartet werden können. Wird in der zu startenden Batch-Datei ein ClassiX-Prozess mit START gestartet, ohne den Parameter /WAIT anzugeben, dann beendet sich der vom Launcher gestartete Prozess sofort wieder und der Launcher kann den ClassiX-Prozss (falls er hängt) auch nicht mehr über die Prozess-ID beenden. Das kann dazu führen, dass sich der Server nicht erfolgreich in den Wartungsmodus versetzen lässt.

Da es schnell passieren kann, dass die Start-Batch falsch konfiguriert wird, muss der Server diese Möglichkeit in betracht ziehen und die Verbindung von der falsch gestarteten Instanz trotzdem akzeptieren. Das kann er nur, indem er das Signal vom Launcher (dass sich die Instanz beendet hat) ignoriert und einen Timeout abwartet (ws.launcher.launch_timeout) ehe er davon ausgehen kann, dass die Instanz nicht erfolgreich gestartet wurde. Dieser Timeout macht den Start-Prozess ineffizienter, als er sein könnte.

Deshalb sollten die Start-Scripte so geschrieben werden, dass sie sich nicht beenden, solange der ClassiX-Prozess noch läuft. Falls das offene Konsolenfenster im Normalbetrieb unerwünscht ist, kann hierfür die Umgebungsvariable CX_START_WAIT verwendet werden, die der Launcher für seine Unterprozesse auf "/WAIT " setzt. 

 

Admin-Konsole startet nicht

Ursachen:

Lösungen:

Sollte die start_console.bat beim Start melden: "Bitte vor der Installation des Dienstes die Batch-Datei setup_dependencies.bat ausführen.", dann fehlen die NodeJS-Abhängigkeiten. Diese können über das Script setup_dependencies.bat aus dem Internet runtergeladen werden. Hierzu muss der Rechner auch Zugriff auf das Internet haben. Sollte hierbei etwas fehlschlagen, dann wird eine npm-debug.log-Datei in dem Verzeichnis abgelegt, der man den Fehler entnehmen kann. Falls der Rechner keinen Zugriff auf das Internet haben darf, dann kann das Script auch auf einem anderen Rechner ausgeführt werden und anschließend der generierte Ordner node_modules auf den Zielrechner kopiert werden.

 

Admin-Konsole kann sich nicht verbinden

Ursachen:

  • Es läuft kein MorphIT-Server
  • Die Konsole wurde nicht auf der gleichen Maschine gestartet
  • Die Admin-Konsole wurde deaktiviert
  • Der konfigurierte Port passt nicht
  • Die SSL-Konfiguration passt nicht

Lösungen:

In den Voreinstellungen des MorphIT-Servers sind aus Sicherheitsgründen nur Verbindungen der Adminkonsole von der Maschine erlaubt, auf der auch der Server läuft. Diese Einstellung sollte nicht geändert werden und die Konsole sollte immer von der gleichen Maschine ausgeführt werden.

In der .../Webservice/morphIT/custom/config.js kann über den Eintrag ws.admin.enabled die Admin-Konsole gänzlich deaktiviert werden. Dieser Wert muss auf true gesetzt werden, damit die Konsole eine Verbindung zum Server aufbauen kann.

Der Eintrag ws.admin.port der Server-Konfiguration gibt an, auf welchem Port sich die Admin-Konsole mit dem Server verbinden kann und dieser muss mit dem Eintrag endpoint.port aus .../Webservice/admin_console/config/config.js, bzw. .../Webservice/admin_console/config/custom/config.js übereinstimmen. 

Läuft der vom Server konfigurierte Port über SSL, dann muss in der .../Webservice/admin_console/config/custom/config.js auch der Eintrag endpoint.ssl auf true gesetzt sein.

 

Wartungs-Server startet nicht

In der Admin-Konsole wurde der maintenance-Befehl abgesetzt, sie meldet jedoch nicht, dass der Maintenance-Server erfolgreich gestartet wurde.

Ursachen:

  • MorphIT-Server ist beim Herunterfahren abgestürzt
  • Der Prozess für den Wartungs-Server konnte nicht gestartet werden
  • Der Wartungsserver hatte beim Starten einen unerwarteten Fehler

Lösungen:

Schnelle Lösung: 

  1. In den Windows-Diensten kontrollieren und sicherstellen, dass der MorphIT-Server (und MorphIT-Launcher) beendet sind (falls nciht, beenden).
  2. CMD öffnen und morphit start mserver ausführen (Erst 4.15.0). Der Wartungsserver wird direkt in der CMD gestartet und eventuelle Fehlermeldungen sind direkt sichtbar.

Alternative Lösung:

In den häufigsten Fällen, reicht es, den Vorgang:

  1. MorphIT-Server (neu-)starten
  2. Per Admin-Konsole In Wartungsmodus versetzen

mehrfach zu wiederholen, um das Problem zu umgehen und den Wartungsserver zu starten. Um das auftretende Problem genauer zu untersuchen (und vielleicht zu beheben) sollte, wie in den nachfolgenden Absätzen beschrieben, vorgegangen werden.

Da der Server für jeden einzelnen Schritt beim Herunterfahren ein Timeout hat, ist es unwahrscheinlich, dass der Server beim Herunterfahren hängt weil er auf etwas wartet. Was sein kann, ist dass ein unerwarteter Fehler aufgetreten ist, der zum Absturz des Servers vor dem Start des Wartungs-Servers geführt hat. Dieser Fehler müsste in .../Webservice/morphIT/logs/server.log auftauchen. Da der Server normalerweise als Dienst eingerichtet ist und das Beenden des Dienstes der letzte Schritt beim Herunterfahren ist, sollte der Server dann ganz normal neu gestartet werden. Dies merkt die Admin-Konsole und setzt den maintenance-Befehl automatisiert erneut ab (bis zu 3 mal). Sollte der Server also regelmäßig beim Herunterfahren abstürzen, kann es dazu führen, dass der Wartungs-Server nicht gestartet werden kann. Der Fehler sollte im Server-Log gesucht und behoben werden.

Sollte der MorphIT-Server keine Rechte haben, den Wartungs-Server als neuen Prozess zu starten, dann kann man das daran erkennen, dass eine cxt...json-Datei mit der Server-Konfiguration unter %TEMP% liegt. Die Datei wird unmittelbar vor dem Start des Wartungs-Servers angelegt und von diesem beim Start gelöscht. Hierzu müsste auch ein Eintrag im Server-Log vorhanden sein. Der Maintenance-Server lässt sich in dem Fall manuell von der CMD starten:

node maintenance_server.js --full-config %TEMP%\cxt...json --console

(Parameter"console" erst ab MorphIT 3.16.5, Vor MorphIT 4.15.0 heißt der erste Parameter einfach nur "config")
Auf diese Weise kann auch über die Konsolenausgabe geprüft werden, ob der Wartungsserver selbst Fehler beim Starten hat.

Der Wartungsserver liest beim Start die Config-JSON und anschließend werden anhand der dort gesetzten Pfade/Werte Dateien in den Speicher geladen und ein Webserver gestartet. Der Wartungsserver erzeugt unter %TEMP% eine Log-Datei mit dem Schema cxm....log, die automatisch gelöst wird, sobald der Maintenance-Server durch einen MorphIT-Server regulär ersetzt wird. Sollte der Wartungsserver beim Start einen Fehler haben, sollte die Log-Datei zum einen die zum starten verwendete Konfiguration enthalten und zum anderen den aufgetretenen Fehler. Um den Wartungsserver manuell neu zu starten kann die Konfiguration (beginnend ab der ersten öffnenden geschweiften Klammer) in eine .json-Datei kopiert werden. Der Server kann dann über den Befehl aus dem vorherigen Absatz manuell gestartet werden.

ClassiX-Instanzen können sich nicht zum Server verbinden

ClassiX-Instanzen lassen sich starten, im Server-Log sieht man aber keinen Verbindungsaufbau. Auch dann nicht, wenn der Server und ClassiX auf der gleichen Maschine laufen.

Ursache:

  • Rechner hat kein Netz und DNS kann localhost nicht auflösen (vor Dll-Version 20013)
  • Firewall blockiert den Zugriff
  • Falsche Verbindungsparameter
  • Aufruf von StartMorphITAutomatically fehlt oder ist fehlerhaft

Lösungen:

Wird MorphIT auf einem Rechner ohne Netzwerkverbindung gestartet, dann kann es sein, dass der Verbindungsaufbau zu localhost fehlschlägt, weil die Namensauflösung von localhost über den nun nicht aktiven DNS-Dienst läuft. Das Problem lässt sich umgehen, indem statt localhost die lokale Loopback-Adresse verwendet wird. 20013: Diese Korrektur ist nicht mehr notwendig, sie wird vom System automatisch vorgenommen.

Je nach dem Modus, in dem MorphIT benutzt wird, muss an einer anderen Stelle korrigiert werden.

  • Interaktiv: In der Start-Batch von ClassiX muss CX_MORPHIT_HOST=127.0.0.1 gesetzt werden
  • Launcher: Unter .../WebService/launcher/config/custom/launcher.js den Eintrag "host":"127.0.0.1" setzen.

Sollte in der Log-Datei des ClassiX-Prozesses nun stehen, dass die Vebrindung aufgebaut wird, aber der Server die Verbindung zurückweist, dann kann auch die Firewall die Ursache für das Problem sein (auch ohne Netz). Kaspersky kommt MorphIT häufiger mal in die Quere. Die Firewall deaktivieren und dann Server und ClassiX neu starten sollte das Problem lösen.

Gibt ClassiX weiterhin aus, dass es sich nicht verbinden kann, stimmen die Verbindungsparameter(CX_MORPHIT_HOST, CX_MORPHIT_PORT, CX_MORPHIT_SSL, CX_MORPHIT_ENDPOINT) möglicher Weise nicht mit denen des Servers überein. Diese müssen so gesetzt sein, wie der Server es in seinem Log in der Zeile "ClassiX should connect to: ..." angibt.

Lässt sich ClassiX zwar starten, baut dann aber keine MorphIT-Verbindung auf, dann fehlt womöglich in der .cxp das Statement webService::StartMorphITAutomatically. Diese Prozedur prüft, ob das ClassiX durch einen Launcher gestartet wurde und liest die Parameter aus den entsprechend gesetzten Umgebungsvariablen und baut dann die Verbindung zum Server auf.

ClassiX-Instanzen melden Ressourcenprobleme

Im Betrieb kommt bricht die aktuell verbundene ClassiX-Instanz ab und zu mit der Fehlermeldung ab, dass nicht genug Ressourcen verfügbar seien.

Ursachen:

  • Arbeitsspeicher aufgebraucht
  • Session-Heap aufgebraucht

Lösungen:

In der Admin-Konsole status --launcher ausführen. Dort kann ist zu jedem Verbundenen Launcher-Prozess aufgeführt, wie viel Speicher auf der Maschine verwendet wird. Ist der Speicher sehr knapp, dann sollte die Zahl der zu startenden ClassiX-Instanzen auf diese Maschine reduziert werden, oder mehr Arbeitsspeicher eingesetzt werden. Die Anzahl der zu startenden Instanzen lässt sich in der .../Webservice/launcher/config/custom/config.js über den Eintrag max_instances steuern.

Sollte in der Admin-Konsole der Arbeitsspeicher nicht ausgelastet sein, dann kann einfach der Session-Heap aufgebraucht sein. Da der Launcher normaler Weise als Dienst läuft und alle Dienste in Session 0 laufen, muss der Session-Heap für diese Session ausreichend groß sein. Standardmäßig ist dieser für Session 0 deutlich kleiner, als für interaktive Sessions. Bevor an den Werten etwas geändert wird, wird empfohlen, den folgenden Beitrag zu lesen und sich klar zu machen, dass eine falsche Konfiguration den Server daran hindern kann, zu booten.

Siehe auch: https://blogs.technet.microsoft.com/askperf/2007/07/24/sessions-desktops-and-windows-stations/ (Link ist tot)
Aktualisierter Link: https://techcommunity.microsoft.com/t5/ask-the-performance-team/sessions-desktops-and-windows-stations/ba-p/372473

Um den Heap für Session 0 zu vergrößeren, muss in der Registry der folgende Eintrag angepasst werden:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\Windows

Dieser enthält einen langen Text, der wie folgt aussieht:
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,20480,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ServerDll=sxssrv,4 ProfileControl=Off MaxRequestThreads=16

Die dritte Zahl hinter SharedSection ist die Größe des Session-Heaps für Session 0 in KB. Damit Ressourcenprobleme nicht mehr auftreten, sollte dieser Wert an den Wert für interaktive Sessions angepasst werden (die zweite Zahl hinter SharedSection).

Durch diese Anpassung wird der Session-Heap deutlich vergrößert. Damit das System hierdurch nicht ausgebremst wird, empfehlen wir zusätzlich unter dem Schlüssel:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
den Eintrag SessionViewSize zu erhöhen. Der Eintrag SessionViewSize gibt an, wie viel Speicher insgesamt (in MB) für Session-Heaps reserviert werden soll. Hier empfehlen wir, den vierfachen Wert des Desktop-Session-Heaps (Hier: 4 x 20 = 80) zu setzen.

Damit die Änderungen übernommen werden, muss der Rechner neu gestartet werden.