Apache 2.4 jest niemożliwy do zabicia i nie można go zatrzymać w systemie Windows Server

11

Mamy dwa Windows Server , jeden w 2012 R2 , a drugi w 2008 R2 , który wykorzystuje Apache HTTP Server ( httpd) 2,4 w proxy / tryb reverse-proxy (użytkowanie ProxyPass, ProxyPassReversei hostów wirtualnych konfiguracji). Oba serwery używają kompilacji binarnej Apache 2.4.27 x64 z Apache Haus.

Mamy kilka skryptów kopii zapasowych działających na obu serwerach. Zatrzymują wszystkie usługi (w tym Apache), a następnie wykonują kopię zapasową i ponownie uruchamiają wszystkie usługi.

Te skrypty działają dobrze od kilku lat (prawie 4 lata). Ale począwszy od July 12, 2018tego zachowanie jest teraz dziwne. Skrypty kopii zapasowej wykonują swoje zadania, zatrzymując wszystkie usługi, wykonując kopię zapasową, ale teraz wszystkie usługi są restartowane z wyjątkiem Apache.

Po zbadaniu okazało się, że usługi Apache 2.4.27 nie można zatrzymać. Podczas korzystania z konsoli Usługi i próby ręcznego zatrzymania usługi konsola wyświetla komunikat „Zatrzymywanie” i nic się nie dzieje.

Sprawdziłem więc uruchomione procesy i zobaczyłem, że httpd.exeproces działa. Próbowałem zabić ten proces, ale bez powodzenia.

Próbowałem więc:

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

Wyjście to:

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

Więc przetestowałem, aby zabić proces z pskillSysinternals:

pskill -t 560

Wyjście to:

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

Process 5956 killed.

Ale to nieprawda, ponieważ httpdproces zawsze trwa!

Zaktualizowałem więc Apache z 2.4.27 do 2.4.34, ale problem pozostaje. Jedyne, co należy zrobić, aby odblokować sytuację, to zrestartowanie całego serwera.

Sprawdziłem zainstalowane aktualizacje, a niektóre z nich zostały zainstalowane na July 11, 2018jeden dzień wcześniej:

  • KB4338420
  • KB4338818
  • KB4339093
  • KB4338423

Zakładam, że problem dotyczy jednej z tych aktualizacji. Czy przed odinstalowaniem ich wszystkich jest ktoś, kto ma taki sam problem jak ja, mam na myśli, że Apache 2.4 staje się niemożliwy do zabicia i nie można go zatrzymać na Windows Server?

Dużym problemem jest to, że jeśli tego httpdprocesu nie można zabić, nie można zrestartować Apache, ponieważ port 80 jest już związany.

SiZiOUS
źródło
3
Tytuł brzmi jak filmowy potwór.
Trotski94,
Poszukiwano

Odpowiedzi:

10

OK, więc myślę, że byłem na dobrej drodze.

Po wyszukaniu w sieci ostatnio zainstalowanych aktualizacji KB4338818 powoduje problemy.

Dzieje się tak w przypadku innych programów, takich jak FileZilla Server, jak wyszczególniono tutaj .

Właśnie odinstalowałem tę aktualizację zabezpieczeń i teraz Apache można normalnie uruchomić / zatrzymać!

Mam więc nadzieję, że Microsoft naprawi to w późniejszej aktualizacji!

SiZiOUS
źródło
Widzę, że znalazłeś swoją odpowiedź, ale zastanawiałem się, czy ponowne uruchomienie serwera również rozwiązałoby problem? Ponadto, jeśli aktualizacja została zastosowana, gdy Apache nie był uruchomiony, możliwe, że nie spowodowała problemów.
MonkeyZeus
Tak, jak już wyjaśniłem w pierwotnym pytaniu, jedynym rozwiązaniem, aby odblokować sytuację, jest ponowne uruchomienie całego serwera ... co jest nieprzyjemnym obejściem!
SiZiOUS
Przepraszam, brakowało mi tego szczegółu, był trochę pochowany. Czy po ponownym uruchomieniu proces nie był możliwy do wywołania? Pytam tylko dlatego, że używam systemu Windows 7 x64 z Apache na moim komputerze lokalnym, ale jeszcze nie otrzymałem KB4338818, więc chcę wiedzieć, czego się spodziewać.
MonkeyZeus,
1
Nie ma problemu, nie musisz uzasadniać swojego komentarza. :) Po ponownym uruchomieniu, jeśli skonfigurowałeś Apache do automatycznego uruchamiania, zadziała. Ale gdy spróbujesz zatrzymać usługę (ręcznie lub przy użyciu skryptów), httpdproces zawiesi się i stanie się niemożliwy do wywołania.
SiZiOUS
1

KB4338831 wydaje się naprawiać problem w systemie Windows Server 2012 R2.

Ta aktualizacja niezwiązana z zabezpieczeniami zawiera ulepszenia i poprawki, które były częścią KB4338815 (wydaną 10 lipca 2018 r.), A także zawiera te nowe ulepszenia jakości jako podgląd następnej comiesięcznej aktualizacji pakietu zbiorczego. Źródło: 18 lipca 2018 r. - KB4338831 (wersja zapoznawcza comiesięcznego pakietu zbiorczego aktualizacji)

Jest dostępny jako zalecana aktualizacja w Windows Update.

Alessandro Brandão
źródło
0

Myślę, że zdecydowanie jesteś na dobrej drodze. Miałem podobny problem z Tomcat na Windows Server. Miałem inny serwer z Tomcat, który jednak nie miał tego problemu, a jedyną znaczącą różnicą, jaką mogłem znaleźć, było to, że działający serwer miał również zainstalowany IIS i działał na innych portach. Aby obejść ten problem, próbowałem załadować IIS na serwer problemów, konfigurując domyślną stronę internetową, tak aby korzystała z niestandardowych portów, a problem wydaje się zniknąć bez konieczności odinstalowywania aktualizacji.

Don Prezioso
źródło
1
OK ... cofam to ... sztuczka IIS wydaje się działać tylko przez pewien czas. Port 80 wydaje się być naprawiony przy ładowaniu IIS, ale 443 działa tylko przez pewien czas. Również dla mnie niepoprawną aktualizacją wydaje się być KB4338815. Przynajmniej dla mojego serwera produkcyjnego jest to jedyna rzecz na nim działająca, więc mogę zrestartować prawie tak łatwo, jak zrestartowanie Tomcat.
Don Prezioso,