Apache 2.4 kann nicht getötet werden und kann unter Windows Server nicht gestoppt werden

Wir haben zwei Windows Server , eine in 2012 R2 und die andere in 2008 R2 , die verwendet Apache HTTP Server ( httpd) 2.4 in proxy / Reverse-Proxy - Modus (Nutzung ProxyPass, ProxyPassReverseund Virtual Hosts - Konfiguration). Beide Server verwenden den Apache 2.4.27 x64-Binärbuild von Apache Haus.

Auf beiden Servern werden einige Sicherungsskripte ausgeführt. Sie stoppen alle Dienste (einschließlich Apache), führen dann die Sicherung durch und starten alle Dienste erneut.

Diese Skripte funktionieren seit mehreren Jahren (fast 4 Jahre) einwandfrei. Aber ab July 12, 2018jetzt ist das Verhalten jetzt seltsam. Die Sicherungsskripte erledigen ihre Arbeit, stoppen alle Dienste und führen die Sicherung durch. Jetzt werden jedoch alle Dienste außer Apache neu gestartet.

Nach einer Untersuchung stellte ich fest, dass der Apache 2.4.27-Dienst nicht gestoppt werden kann. Wenn Sie die Dienstekonsole verwenden und versuchen, den Dienst manuell zu beenden, zeigt die Konsole "Stoppen" an und es passiert nichts.

Also habe ich die laufenden Prozesse überprüft und festgestellt, dass ein httpd.exeProzess ausgeführt wird. Ich habe versucht, diesen Prozess zu beenden, aber ohne Glück.

Also habe ich versucht:

taskkill /im "httpd.exe" /f /t

Und die Ausgabe ist:

ERROR: The process with PID 560 (child process of PID 480) could not be terminated.
Reason: There is no running instance of the task.

Also habe ich getestet, um den Prozess mit pskillvon Sysinternals zu beenden:

pskill -t 560

Und die Ausgabe ist:

Copyright (C) 1999-2016  Mark Russinovich
Sysinternals - www.sysinternals.com

Process 5956 killed.

Dies ist jedoch falsch, da der httpdProzess immer ausgeführt wird!

Ich habe Apache von 2.4.27 auf 2.4.34 aktualisiert, aber das Problem bleibt bestehen. Das einzige, was Sie tun müssen, um die Situation zu entsperren, ist ein Neustart des gesamten Servers.

Ich habe die installierten Updates überprüft und einige davon wurden July 11, 2018einen Tag zuvor installiert :

• KB4338420
• KB4338818
• KB4339093
• KB4338423

Ich gehe also davon aus, dass das Problem von einem dieser Updates herrührt. Gibt es also vor der Deinstallation von allen jemanden, der das gleiche Problem wie ich hat ? Ich meine, Apache 2.4 kann nicht mehr getötet werden und kann unter Windows Server nicht gestoppt werden?

Das große Problem ist, dass httpdApache nicht neu gestartet werden kann , wenn dieser Prozess nicht abgebrochen werden kann, da der Port 80 bereits gebunden ist.

OK, ich glaube ich war auf dem richtigen Weg.

Nach der Suche im Web nach den kürzlich installierten Updates verursacht der KB4338818 Probleme.

Dies geschieht für andere Software wie FileZilla Server, wie hier beschrieben .

Ich habe dieses Sicherheitsupdate gerade deinstalliert und jetzt kann Apache wie gewohnt gestartet / gestoppt werden!

Ich hoffe, Microsoft wird dies in einem späteren Update beheben!

Microsoft veröffentlicht KB4345459, um die Probleme in Windows 7 und Windows 2008 Server zu beheben.

https://support.microsoft.com/en-us/help/4345459/stop-error-0xd1-after-a-race-condition-occurs-in-windows-7-service-pac

Microsoft scheint das Problem zu beheben, bisher nur für Server 2016 und Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

KB4338831 scheint das Problem für Windows Server 2012 R2 zu beheben.

Dieses nicht sicherheitsrelevante Update enthält Verbesserungen und Korrekturen, die Teil von KB4338815 (veröffentlicht am 10. Juli 2018) waren, sowie diese neuen Qualitätsverbesserungen als Vorschau auf das nächste monatliche Rollup-Update. Quelle: 18. Juli 2018 - KB4338831 (Vorschau des monatlichen Rollups)

Es ist als empfohlenes Update für Windows Update verfügbar.

Ich denke, Sie sind definitiv auf dem richtigen Weg. Ich hatte ein ähnliches Problem mit Tomcat auf einem Windows Server. Ich hatte einen anderen Server mit Tomcat, auf dem das Problem jedoch nicht auftrat, und der einzige große Unterschied, den ich feststellen konnte, war, dass auf dem Arbeitsserver auch IIS installiert war und auf anderen Ports ausgeführt wurde. Als Workaround habe ich versucht, IIS auf den Problemserver zu laden und die Standardwebsite so einzurichten, dass nicht standardmäßige Ports verwendet werden und das Problem anscheinend behoben ist, ohne dass das Update deinstalliert werden muss.