Назад | Перейти на главную страницу

Apache 2.4 нельзя убить и его нельзя остановить на Windows Server

У нас есть два Windows Server, один в 2012 R2 а другой в 2008 R2 который использует HTTP-сервер Apache (httpd) 2,4 в режиме прокси / обратного прокси (использование ProxyPass, ProxyPassReverse и конфигурация виртуальных хостов). Оба сервера используют Apache 2.4.27 x64 бинарная сборка из Apache Haus.

У нас есть несколько сценариев резервного копирования, работающих на обоих серверах. Они останавливают все службы (включая Apache), затем делают резервную копию и снова перезапускают все службы.

Эти скрипты отлично работают уже несколько лет (почти 4 года). Но начиная с July 12, 2018, поведение теперь странное. Сценарии резервного копирования выполняют свою работу, останавливая все службы, выполняя резервное копирование, но теперь все службы перезапущены, кроме Apache.

После расследования я обнаружил, что службу Apache 2.4.27 невозможно остановить. При использовании консоли служб и попытке вручную остановить службу консоль показывает «Остановка» и ничего не происходит.

Итак, я проверил запущенные процессы и увидел, что httpd.exe процесс запущен. Я пытался остановить этот процесс, но безуспешно.

Итак, я попробовал:

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

И результат:

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

Итак, я попробовал убить процесс с помощью pskill из Sysinternals:

pskill -t 560

И результат:

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

Process 5956 killed.

Но это неверно, поскольку httpd процесс всегда запущен!

Итак, я обновил Apache с 2.4.27 до 2.4.34, но проблема остается. Единственное, что нужно сделать, чтобы разблокировать ситуацию, - это перезагрузить весь сервер.

Я проверил установленные обновления, и некоторые из них были установлены July 11, 2018 так что накануне:

Итак, я предполагаю, что проблема связана с одним из этих обновлений. Итак, прежде чем удалять их все, есть ли у кого-то такая же проблема, как у меня, я имею в виду Apache 2.4 становится неубиваемым и его нельзя остановить на Windows Server?

Большая проблема, если это httpd процесс не может быть убит, Apache не может быть перезапущен, так как порт 80 уже привязан.

Ладно, думаю, я был на правильном пути.

После поиска в Интернете недавно установленных обновлений KB4338818 вызывает проблемы.

Это происходит с другим программным обеспечением, таким как FileZilla Server, как подробно здесь.

Я только что удалил это обновление безопасности, и теперь Apache можно запускать / останавливать как обычно!

Так что я надеюсь, что Microsoft исправит это в более позднем обновлении!

Microsoft выпускает KB4345459 для устранения проблем в Windows 7 и Windows 2008 Server.

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

KB4338831, похоже, решает проблему для Windows Server 2012 R2.

Это обновление, не связанное с безопасностью, включает улучшения и исправления, которые были частью KB4338815 (выпущено 10 июля 2018 г.), а также включает эти новые улучшения качества в качестве предварительного просмотра следующего ежемесячного накопительного пакета обновлений. Источник: 18 июля 2018 г. - KB4338831 (предварительная версия ежемесячного накопительного пакета)

Он доступен в качестве рекомендуемого обновления в Центре обновления Windows.

Похоже, что Microsoft начинает исправлять проблему, до сих пор только для Server 2016 и Windows 10: https://support.microsoft.com/de-de/help/4345421/windows-10-update-kb4345421

Я думаю, вы определенно на правильном пути. У меня была аналогичная проблема с Tomcat на Windows Server. У меня был другой сервер с Tomcat, который не испытывал проблемы, и единственное существенное различие, которое я смог найти, заключалось в том, что на рабочем сервере также был установлен IIS, который работал на других портах. В качестве временного решения я попытался загрузить IIS на проблемный сервер, настроив веб-сайт по умолчанию, чтобы он использовал нестандартные порты, и проблема, похоже, исчезла без необходимости удаления обновления.