Ошибка запуска сервиса Apache 2.4 под Windows 10
- 26 января 2023
- Автор: Сергей Кузнецов
- Просмотров: 3638
Ошибка запуска сервиса Apache 2.4 под Windows 10
Как то, в совершенно обычный день дернул один из локальных сайтов (Apache 2.4 на Windows 10) и обнаружил "пустоту" в браузере. Посмотрел в логи Apache 2.4 и обнаружил, что уже почти неделю там ничего не появлялось, а следовательно, скорее всего не стартует сервис Apache. И действительно, заглянув в диспетчер задач, увидел, что служба Apache2.4 не запущена. Попытки ее запустить ручками заканчивалась неудачей.
Поход в просмотр событий приложений в Windows принес следующие результаты:
The Apache service named reported the following error:
>>> (OS 10013)Сделана попытка доступа к сокету методом, запрещенным правами доступа. : AH00072: make_sock: could not bind to address [::]:80 .
The Apache service named reported the following error:
>>> AH00451: no listening sockets available, shutting down .
Предварительный вывод: Кто-то занял сокет до старта Apache...
И вот тут сразу встали несколько вопросов:
- Что же произошло и как?
- Как исправить?
Первым делом начал вспоминать, что же я такого ставил/обновлял за эту неделю.
- Windows 10 - обновления не устанавливались (если верить списку обновлений)
- Несколько мелких приложений, которые были сразу снесены, но это результата не принесло, хотя и сразу было предположение, что это не они...
Попытка поиска в интернете привела к относительно старым сообщениям, но вполне разумным, что какое то из приложений захвалило сокет. Наиболее часто предлагалось проверить Skype, IIS (), SQL Server Reporting Services и некоторые другие, но и это результата не принесло.
Т.о. возникла необходимость уже внимательно на все посмотреть и определить, кто же так нагло и незаметно сел на 80 порт. Для этого в командной строке толкаем:
>netstat -ao
И ее выдаче смотрим, какой процесс висит на 80 порту и видим Process ID = 4 (PID):
Имя Локальный адрес Внешний адрес Состояние PID
TCP 0.0.0.0:80 computer-name:0 LISTENING 4
Затем идем в диспетчер задач и в процессах нас ждет небольшое открытие - PID 4 - это System (C:\Windows\System32\ntoskrnl.exe - NT Kernel & System), которое "убить" не получится (Windows этого не переживет).
Выход - найти, кто же реально через "NT Kernel & System" захватил сокет. Ну, и ведь не просто так там что-то висит...
Для этого пытаемся обратиться к порту в командной строке используя telnet:
>telnet 127.0.0.1 80
Получив пустой экран (нет ни каких сообщений, следовательно telnet достучался и то, что там висит ждет от меня команды), набираю несколько любых символов, затем жму Enter и в ответ получаю вот такое:
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Thu, 26 Jan 2023 09:25:01 GMT
Connection: close
Content-Length: 326
И вот он, виновник: Microsoft-HTTPAPI/2.0! С помощью интернета определяем, что за это отвечает почти "одноименный" файлик httpapi.dll. и с помощью команды смотрим список процессов, его использующих:
> tasklist /M httpapi.dll
И вот мы видим список реальных кандидатов. Кто-то из них через ядро захватил необходимый нам сокет.
Имя образа PID Модули
========================= ====
vmms.exe 2744 HTTPAPI.dll
svchost.exe 3120 HTTPAPI.dll
svchost.exe 3700 httpapi.dll
OneApp.IGCC.WinService.exe 5680 httpapi.dll
svchost.exe 6040 HTTPAPI.dll
svchost.exe 7536 HTTPAPI.dll
KeePass.exe 5584 httpapi.dll
w3wp.exe 13324 HTTPAPI.dll
Как же определить, кто из них?
Поочередно находим эти процессы в диспетчере задач и смотрим, что это такое. В общем, если не копать еще глубже, то просто смотрим, а что из этого относится к Web и что потенциально может повиснуть на 80 порту (порт, по умолчанию, для http серверов без SSL).
И вот, на 6040 порту видим такое наименование процесса (подозрительно уже то, что это как-то связано с IIS. Если бы внимательно просмотреть все сервисы, то можно было бы его увидеть и попробовать отключить без изысканий. Но кто же в этом огромном списке сервисов будет внимательно искать что-то подозрительное. Т.ч. пришлось сначала сократить список поиска до конкретных PID...):
- Узел службы: служба IIS (2)
А развернув его, видим две службы, одна из которых очень подозрительна (верный кандидат - "W3CVC"/"Служба веб-публикаций"):
- Служба веб-публикаций
- Служба активации Windows
Проверяем наши догадки.
- Находим в диспетчере задач в службах/сервисах службу "Служба веб-публикаций" и останавливаем ее.
- Находим в диспетчере задач в службах/сервисах службу "Apache2.4" и запускаем ее. Apache запустился - значит виновник определен правильно - это "Служба веб-публикаций"
- Находим в диспетчере задач в службах/сервисах службу "Служба веб-публикаций", идем по "Открыть в службах", находим ее и в свойствах выставляем "Ручной запуск".
- Перегружаем комп и видим, что наш Apache2.4 успешно стартует...
И так, проблема решена - Apache2.4 вернулся к обычной жизни.
Но как же такое случилось?
Ведь обновлений Windows не было. Ничего, что бы на первый взгляд, могло повлиять на подобное поведение вроде тоже не было. Так что, это останется, наверное тайной, т.к. разбираться в этом нет ни какого желания.
