Vor einigen Wochen hatte ich Probleme mit meinem Server gehabt, der nicht mehr stabil lief und herumzickte. Nachdem ich den MySql-Server (den ich eh nicht brauchte, sondern nur irgendwann zu Testzwecken installiert hatte) deinstalliert, und den Rechner gebootet hatte, schien dieser wieder ordentlich zu laufen.
Erst nach und nach musste ich jedoch feststellen, dass einige Dienste, die ich darauf eingerichtet hatte, nicht mehr oder nur noch eingeschränkt liefen.
Da die Dringlichkeit dieser Dienste nicht wirklich kritisch ist, und ich außerdem sowieso mit wichtigeren Angelegenheiten beschäftigt bin, musste ich die Behebung dieser Probleme erst mal zurückstellen.
Als ich endlich dazu kam (nicht am Stück, aber mehrmals jeweils etwa eine halbe bis ganze Stunde), mir den Server wieder anzuschauen, probierte ich einiges herum. Ich schaute vor allem in meinen Sourcen nach, was da schiefgelaufen sein könnte, so dass ein bestimmter Dienst gar nicht erst startete.
Eine mögliche Ursache hätte sein können, dass der Service bei seiner Initialisierung die Logdatei nicht hätte anlegen können. Ich überprüfte mehrfach den Pfad, ob das Verzeichnis existiert, und auch ausreichende Berechtigungen vorhanden sind.
Eine andere potentielle Fehlerquelle (die durch Meldungen im Eventviewer gestützt schien) war das Fehlschlagen der Bindung des Sockets an den dafür vorgesehenen Port. Ich überprüfte Registryeinträge, die Firewall, schaute mit netstat nach, welche Ports überhaupt belegt waren, und einiges mehr. Alle Konfigurationen schienen in Ordnung zu sein.
Trotzdem machte ich in der Registry händisch ein paar Änderungen, um andere Optionen für die Initialisierung zu setzen, und startete den Dienst neu. Alles wie gehabt.
(Wenigstens kann ich das alles von remote aus machen, und muss nicht extra deswegen runter in den Serverraum.)
Irgendwann wunderte ich mich, dass die Registryeinträge unter dem üblichen Key gespeichert waren. Schließlich läuft mein Server auf 64 bit, während meine Dienste 32-bittig sind. Ich probierte dann – quasi als letzten Strohhalm – ob sich etwas ändern würde, wenn ich die Einträge in den Wow6432Node-Hive legen würde. Gedacht, getan. Service neu gestartet, und – Heureka! Bingo! Geschafft! – der Dienst lief wieder einwandfrei.
Wenn der Dienst nicht die für ihn vorgesehenen Registryeinträge gefunden hat, dann versuchte er, mit Defaultparametern zu starten. Unter anderem war das ein Port, der bereits von einem anderen Dienst besetzt war. Nur mit den gültigen Werten in der Registry kann er bestimmungsgemäß laufen.
Der nächste Dienst hatte zwar gestartet und lief, ich konnte mich auch mit ihm verbinden, aber jedesmal, wenn ich ihm eine Aufgabe geben wollte, brach er diese mit lapidarer Fehlermeldung (im Eventviewer sichtbar) ab.
Auch da übertrug ich die Registry-Einträge in den Hive für die 32-bit-Anwendungen. Dienst neu gestartet. Success. Der Dienst muss einen Pfad nicht gefunden haben, den er aber brauchte, um bestimmte Dateien zu laden. Ohne diese Dateien brach der Algorithmus ab.
Beim dritten Dienst vermutete ich ebenfalls, dass die Registrydaten nicht am richtigen Platz sind. Den hatte ich zwischenzeitlich schon deinstalliert und wieder neu installiert. Aber hier muss außerdem noch irgendein anderes Problem sein. Der Dienst selbst läuft zwar, aber das was er machen soll, macht er nicht richtig. Ich werde dran bleiben, und ihn schon wieder hinkriegen. Hätte ich doch mehr Zeit, um solches Troubleshooting nicht immer wieder unterbrechen zu müssen.
Jetzt frage ich mich nur, was da genau auf dem Server passiert ist. Früher liefen die Dienste ja bereits ordnungsgemäß, obwohl die Registryeinträge nur im Standardkey vorhanden waren. Wieso plötzlich nicht mehr? Oder hatte es die Registry so zerhaut, dass die in der 32bit-Node vorhandenen Einträge irgendwie gelöscht wurden? Eigentlich gibt es keinen Anhaltspunkt dafür, dass die Registry damals beschädigt wurde.
Ein Quell der Fehler sind immer wieder automatische Updates. Aber dann solltest du etwas im Netz dazu finden.
LikeLike
Das hatte ich mir auch überlegt.
Aber – soweit ich es nachvollziehen kann – kommt dafür eigentlich kein Update infrage, das ich in Verdacht hätte.
LikeLike
Seltsam, seltsam …..
LikeLike
Wenn man mit Computerkram zu tun hat, muss man sich früher oder später damit abfinden, nicht alles nachvollziehen zu können.
Hauptsache, es läuft überhaupt. Warum und wie ist nebensächlich.
LikeLike
Nee, da bin ich anders. Ich muss der Sache auf den Grund gehen und muss verstehen, warum es so ist wie es ist. Es lässt mir dann auch keine Ruhe.
Kannst du ein Backup einspielen oder zur Not eine Neuinstallation machen ? Geht vielleicht schneller als die Fehlersuche.
LikeLike
Der Sache auf den Grund zu gehen, kostet für gewöhnlich halt viel zu viel Zeit.
Nee, das letzte Problem mit dem dritten Service werde ich auch so schon noch irgendwie lösen.
Bis ich da vielleicht irgendwo ein altes Backup finde, das einspiele, und dann funktioniert’s eventuell doch nicht .. nö, lohnt sich nicht.
LikeGefällt 1 Person
Was bin ich froh, dass ich unter z/os arbeite…
LikeLike
Das hat bestimmt auch seine Fallstricke.
Wenn Initialisierungsparameter nicht richtig eingelesen werden, gibt es halt Probleme.
An PHP habe ich mir da auch schon die Zähne ausgebissen, weil es die Ini-Dateien nicht unbedingt da sucht, wo sie sind.
LikeLike
z/os wird immer im Team betrieben, da gibt es für jede Nische Spezialisten und zusammen ist kaum etwas unklar.
LikeLike
Na gut, dann weiterhin erfolgreiches Schaffen!
LikeLike
Eventuell könnten Keys gelöscht worden sein beim deinstallieren des MySql-Servers, die auch von anderen Diensten gebraucht wurden?
LikeLike
Das kann ich eigentlich ausschließem. Es waren nur Keys, die ausschließlich von meiner Software genutzt werden (Unterschlüssel von HKLM\Software\breakpoint).
LikeGefällt 1 Person
Klingt jedenfalls so, als wäre multiarch unter Windows auch heute noch immer ein ziemlicher Krampf. Das erklärt dann auch, warum bis vor wenigen Jahren auf Windows-PCs immer noch 32-Bit-Installationen vorherrschend waren, während der Rest der Welt schon vor 10 Jahren auf 64 Bit Betriebssysteme umgeschwenkt hat.
LikeLike
Für die normale Anwendung sehe ich eigentlich keinen Vorteil, auf 64 bit zu wechseln.
Im Gegenteil – braucht mehr Speicherplatz, Performance kann sogar schlechter sein, Gleitkommaoperationen sind ungenauer, ..
LikeLike
Man sollte doch eigentlich meinen, dass bei 64 Bit Gleitkommaoperationen genauer sind, da pro Zahlenwert ein größerer Speicherraum zur Verfügung steht? Oder ist das mal wieder so eine Windows-spezifische Sache, wo sich die Entwickler mit in die Nesseln gesetzt haben?
LikeLike
Liegt nicht an Microsoft, sondern der Prozessorarchitektur.
LikeLike
Also ein AMD64-Problem, bzw. i386-Problem? Dann könnte es ja bei ARM, die dieser Architektur zunehmend Konkurrenz macht, anders sein. (Keine Ahnung, wie es da ist, auf so tiefer Ebene kenne ich mich damit nicht aus)
LikeLike
Die x86-Prozessoren haben noch 80-bittige Gleitkommazahlen unterstützt.
LikeLike
Pingback: Schon wieder Tweets //2076 | breakpoint
Pingback: General Projection Fault //2358 | breakpoint