Apache 2.2 unter Windows Server: Startet nicht, nachdem versucht wurde, den Laufwerksbuchstaben aller Daten und Protokolle zu ändern

Ich verwalte einen Webserver, der unter Windows Server 2008 als virtueller 64-Bit-Host ausgeführt wird. Die gesamte Service-Software wird unabhängig und nicht als Teil eines AMP-Stacks ausgeführt. Das Datenlaufwerk ist fast voll und mein Systemadministrator hat ein neues virtuelles Laufwerk mit mehr Speicherplatz bereitgestellt. Meine Aufgabe ist es, alles vom alten auf das neue Volume zu kopieren.

Wenn das Volumen zu schaffen, sichergestellt ich , dass es mit dem gleichen Volumen Typ, Dateisystem - Blockgröße erzeugt wurde, usw. ich alle relevanten Dienste beendet (Apache, MySQL, von denen beide ausgeführt von C: aber deren Daten Alle ist auf D:, einschließlich Protokolle) und kopierte alle Dateien über.

Von hier aus habe ich zwei verschiedene Ansätze ausprobiert, um die Dienste vom neuen Volumen abhängig zu machen und das alte zu vergessen. MySQL hat in beiden Fällen keine Probleme, aber Apache kann mit beiden Methoden nicht als Dienst gestartet werden. Folgendes wird im Systemereignisprotokoll angezeigt:

Der Apache2.2-Dienst wurde mit einem dienstspezifischen Fehler beendet. Falsche Funktion

Nichts erscheint in error.log.

Zuerst habe ich versucht, einfach die Laufwerksbuchstaben zu ändern. Ich nahm das alte D: und änderte es in etwas Beliebiges und ordnete D: dem neuen Band zu. Dies ergab den obigen Fehler. Ich habe versucht, den Server mit den neuen Laufwerksbezeichnungen "nur für den Fall" neu zu starten, aber der gleiche Fehler ist aufgetreten. Da ich die Windows-Einhängepunkte nicht vollständig verstehe, habe ich die Laufwerksbuchstaben wieder auf den ursprünglichen Wert geändert und bestätigt, dass der Apache-Dienst einwandfrei startet.

Zweitens habe ich versucht, einfach alle Apache- und MySQL-Konfigurationsdateien zu aktualisieren. Jedes Auftreten von "D:" (ohne Berücksichtigung der Groß- und Kleinschreibung) wurde in F: (der neue Laufwerksbuchstabe) geändert. Ich kenne die Konfigurationsdateien gut, daher weiß ich, dass ich jedes Vorkommen gefunden habe. Der obige Fehler trat erneut auf genau die gleiche Weise auf. Um den Webserver wieder zum Laufen zu bringen, habe ich alle Änderungen rückgängig gemacht und die Dienste erfolgreich gestartet.

Einige weitere Informationen, die ich gesammelt habe:

• httpd.exe wird erfolgreich ausgeführt, wenn es nicht als Dienst über die Befehlszeile gestartet wird. Es gibt keine Syntaxfehler.
• Selbst wenn Apache über die Befehlszeile ausgeführt wird, wird es nicht als Dienst gestartet ( httpd.exe -k runservice).
• Das Problem liegt wahrscheinlich nicht in den Dateizugriffsberechtigungen. Ich habe die wichtigsten Speicherorte (einige Verzeichnisse, Protokolldateien) vor Ort überprüft, und die Berechtigungen waren identisch. Ich habe dies jedoch nicht ausführlich getestet.

Eine Sache, die ich nicht getestet habe, ist zu versuchen, nur einen der Daten- und Protokollspeicherorte auf das neue Laufwerk zu verschieben, während der andere unverändert bleibt. Ich dachte nicht, dass das einen Unterschied machen würde.

... Das heißt, ich weiß eigentlich nicht, was hier los ist. Ich kann mir keinen Grund vorstellen, warum Apache nicht als Dienst ausgeführt werden kann, wenn nur der Speicherort der Protokolldateien und -daten geändert wird.

Ich würde mich über Vorschläge oder Ratschläge zu diesem Thema sehr freuen. Gerne untersuche ich weitere Vorschläge. Wenn einer von Ihnen der Meinung ist, dass es sich lohnt, nur eines der Elemente (Protokolle oder Daten) wie erwähnt zu verschieben, werde ich das versuchen. Wenn einer von Ihnen der Meinung ist, dass ich zu schnell Berechtigungen abgezinst habe, werde ich eine gründlichere Prüfung durchführen.

Jede Eingabe ist willkommen! Ich habe alle meine Ideen erschöpft.

Am nächsten Tag versuchte ich innerhalb des zugewiesenen Zeitfensters für die Deaktivierung der primären Funktionalität des Servers etwas Neues und hatte einen neuen Gedanken, der das Problem schließlich löste! Die Details sind im Zusammenhang mit den von mir unternommenen Schritten wie folgt.

Ich begann damit, den zweiten Ansatz aus der ursprünglichen Frage zu wiederholen. Ich habe die Dienste gestoppt, alle Dateien erneut kopiert (um Änderungen am letzten Tag abzufangen) und die Apache- und MySQL-Konfigurationsdateien so bearbeitet, dass sie auf das neue Laufwerk verweisen (F :). Ich habe bestätigt, dass Apache den gleichen Fehler erzeugt. Da ich die Konfigurationsdateien bereits geöffnet hatte, habe ich beschlossen, zu versuchen, was ich anfangs nicht versucht habe (und eigentlich hätte versuchen sollen):

• Ich habe die Konfigurationsdateien zurückgesetzt, damit sie wieder im ursprünglichen Zustand sind und auf das alte Laufwerk (D :) zeigen.
• Ich habe nur die Verweise auf Protokolldateien auf dem neuen Laufwerk (F :) aktualisiert und den Apache-Dienst getestet - der gleiche Fehler wie zuvor.
• Ich habe die Protokolldateiverweise auf D: zurückgegeben und die Datenverweise auf F: - IT WORKED! Ich hätte es gestern wirklich versuchen sollen. Aus diesem Schritt habe ich gelernt, dass die Protokolldateien das Problem waren.
• Da es nur zwei Dateien ( access.logund error.log) gab, erzwang ich die Berechtigungsänderungen: schreibgeschützt hinzugefügt / entfernt (nur für den Fall), stellte sicher, dass der Apache-Benutzer rekursiven Schreibzugriff über die Verzeichnisse und auf die Dateien selbst hatte.
• Aktualisierte Protokolldateiverweise auf F: - Gleicher Fehler wie zuvor.
• Aus Versehen habe ich die beiden Protokolldateien umbenannt (eine gängige Technik zum Drehen von Protokolldateien) und versucht, den Dienst zu starten, in der Erwartung, dass neue Versionen der ursprünglichen Dateinamen angezeigt werden - das haben sie! Der Dienst wurde erfolgreich gestartet! Sieg!!

Was ich gelernt habe: Eigentlich bin ich mir nicht ganz sicher. Wenn ich die verschiedenen Schritte meiner Untersuchung nicht so gründlich durchgeführt hätte, würde ich problematische Dateihandles oder ähnliches vermuten, aber ich kann nicht sehen, wie dies nach einem Neustart möglich wäre. Ich habe jedoch den Wert bestätigt , Möglichkeiten bei der Fehlerbehebung nicht zu schnell zu schließen. Wie ich in der Frage erwähnt habe, habe ich nicht gedacht, dass die heutige Untersuchungslinie einen Unterschied machen würde, und ich weiß immer noch nicht, warum das so ist! Aber mit Ergebnissen kann man nicht streiten.

Fazit: Mein Problem wurde gelöst, aber ich weiß nicht warum. Wenn jemand eine Theorie hat, teilen Sie sie bitte!

Ich habe keine Ahnung, warum das Ändern des Laufwerksbuchstabens das Problem verursacht. Der Fehler The service terminated with service-specific error Incorrect functionin den Windows-Diensten ist jedoch normalerweise auf einen Mangel an physischem RAM zurückzuführen.

Überprüfen Sie die Mindestsystemanforderungen für Apache-Dokumente und versuchen Sie bei Bedarf, unnötige Programme zu schließen.

Ich bin gerade auf das gleiche Problem mit mod_wsgi gestoßen WSGIPythonHome. Aufgrund der Antwort von nmjk entschied ich mich, die Berechtigungen zu überprüfen und stellte fest, dass der Apache-Benutzer keine Berechtigungen für das WSGIPythonHomeVerzeichnis hatte. Nach dem Hinzufügen der richtigen Berechtigungen wurde Apache normal gestartet.

Vielleicht lohnt es sich, die Berechtigungen für alle in der Konfiguration angegebenen Pfade zu überprüfen und alle Konfigurationen, die einen Pfad enthalten, zeilenweise zu kommentieren, um herauszufinden, welcher das Problem verursacht.

Mein Problem war identisch, ich hatte die Protokollordner auf ein neues Laufwerk verschoben. Ich habe die Anweisungen zum Umbenennen der Datei error.log befolgt und versucht, Apache zu starten, aber es ist mit demselben Fehler fehlgeschlagen. Also habe ich meinen Windows 10-Computer neu gestartet und Apache erfolgreich gestartet.