Время на прочтение3 мин
Количество просмотров193K
Уже не раз сталкивался с проблемой, что Apache не может запустится из-за того, что другой процесс уже использует 80 порт. Собственно после долгого и мучительного серфинга по просторам русскоязычного, а потом и англоязычного интернета насобирал всесозможные способы устранения и причины появления данной проблемы. Эти самые причины и способы их решения и хочу перечислить здесь.
(OS 10048) Only one usage of each socket address (protocol/network address/port) is normally permitted. : make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Самая простая и обыденная причина появления данной проблемы это Skype.
Первым делом необходимо проверить настройки Skype. Идем в Инструменты/Настройки/Дополнительно/Соединение/ и убираем галочку «Использовать порты 80 и 443 в качестве входящих альтернатив». Сохраняем и перезапускаем Skype чтобы настройки вступили в силу. Да и лучше повторно перепроверить эту настройку, потому что бывало, что она не сохранялась по неизвестной причине.
Если не помогло, то надо поискать что за процесс использует наш порт.
Открываем консоль: Главное меню->Выполнить-> вводим cmd и жмем enter.
В консоли вводим следующую команду
netstat -aon | findstr 0.0:80
Левая часть команды вернет нам текущее состояние всех портов, а правая найдет в них нужный нам 80 порт.
Смотрим результат и ищем последний столбец PID. Запоминаем его. Это идентификатор требуемого процесса.
Если это процесс с PID не равный 4, то делаем следующее.
Идем в Диспетчер задач и ищем необходимый нам процесс. По умолчанию PID не выводится. Для этого идем в Вид/Выбрать столбцы и ставим галочку у «ИД процесса(PID)». Сохраняем и видим что рядом с именем процесса появился столбец «ИД процесса».
Ищем процесс с требуемым идентификатором. Там поступаете с этим процессом как хотите, можете просто убить его, убрать из автозагрузки, удалить всё приложение и т.п.
В случае, когда PID был равен 4, это означает что 80 порт используется системой (системным процессом) и в Диспетчере задач вы увидите имя процесса System.
Более быстрый способ найти имя процесса предложил 074909, за что ему отдельное спасибо:
В консоли надо ввести следующую команду:
for /f "tokens=1,2,3,4,5*" %i in ('netstat -aon ^| findstr ":80" ^| findstr /i listening') do echo %j %l & @tasklist | findst
r %m
которая и вернет имя необходимого процесса.
Тут существует несколько решений и какое вам подойдет одному только богу известно.
Первое.
Это проделки некоторых служб:
- Windows Remote Management — Службы удаленного управления
- Sql server reporting services(MSSQLSERVER) — Cлужбы Reporting Services (SSRS) — Службы отчетов SQL Server
- Web Deployment Agent Service
Собственно необходимо эти службы отключить.
- ПКМ по «Мой компьютер»
- Управление
- Службы и приложения
- Службы
- Находим необходимые службы и останавливаем их.
Если не помогло, то можете включить их обратно =) и переходить к следующему пунтку. Тоже самое нужно сделать если вы не нашли этих служб у себя( я у себя на win7 только WinRM нашел).
Второе.
Проделки ‘http.sys’
Тут я нашел 2 способа, не сильно отличающиеся друг от друга, мне помог именно 2ой, однако судя по комментариям 1ой тоже помог не малому количеству народа.
Начинаются они одинаково.
1) Идем в реестр. Выполнить->regedit
2) В ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP
И отличие в этих способах:
3) Создаем параметр типа Dword c именем «NoRun» и присваиваем ему значение «1» без кавычек.
или
3) Ищем параметр «Start» и меняем значение на «0» без кавычек естественно.
4) Перезагружаем компьютер.
Радуемся жизни =)
Материалы:
http://www.mydigitallife.info/how-to-check-and-identify-which-application-is-listening-or-opening-port-80-and-443-on-windows/
http://superuser.com/questions/43307/whys-is-system-process-listening-on-port-80
http://stackoverflow.com/questions/1430141/port-80-is-being-used-by-system-pid-4-what-is-that
http://serverfault.com/questions/65717/port-80-is-being-used-by-system-pid-4-what-is-that
http://www.cameroncooke.com/2009/01/25/windows-7-uses-port-80-and-makes-it-impossible-to-install-apache-solution/
Scenario
On your Windows computer, Apache does not start. Go to the event viewer and find the event with error:
AH00072: make_sock: could not bind to address [::]: 80
Problem
The problem is that an application is using the same port 80 as your site on Apache. How to find out what this application is?
Open the command prompt (cmd). Type
netstat -ano
You see all open ports on your computer used by applications. Find the line that (in this case) is about port 80. The PID column shows the number of the program that is using your port.
Open task manager, in the tab “Details” through the PID column you will find the program that is using your port.
Solution
You have 2 possibilities: either stop the program or, if you need the program, change the port used by this program, if possible, or the one used by Apache.
If the program you found through the PID is System, it means that Windows itself is blocking the door. Open the services and you need to stop the “World Wide Web Publishing Service” service. You will also have to set the start in manual, if instead it were in Automatic, because otherwise the next day the problem would reoccur.
Windows
Apache Error make_sock: could not bind to address 80
This tutorial will teach you how to resolve the following Apache error during startup. An attempt was made to access a socket in a way forbidden by its access permissions. : AH00072: make_sock: could not bind to address [::]:80
80 is the standard default port used for HTTP communication by the Apache Server. In this scenario, you want the Apache server to run on this port.
Error Trace
(OS 10013)An attempt was made to access a socket in a way forbidden by its access permissions. : AH00072: make_sock: could not bind to address [::]:80
Fix
The error is because of port conflict. The Apache is trying to start on port 80, however the port 80 is being used or blocked by another application or server. When two or more applications are trying to use the same port its called as port conflict.
Check the process that is using the port 80.
/> netstat -qo
In this case the IIS server is running on port 80. This could be the most possible case but not always true. The first intelligent guess is the standard servers that run on port 80!
Try to find the process with the process ID.
/> tasklist
tasklist is the command line tool to display the processes and the associated IDs. This command is equivalent to ps utility in Linux.
Alternatively, try accessing the webpage to know the application. We can omit the port number 80 as it is the default port
http://localhost:80
Decide which process should be running on port 80. Change the default port for the IIS server or stop the server.
Start and run the Apache server to resolve the port conflict error.
That’s it!
Related Links
More information on Apache HTTP web server:
https://apache.org/
22 сентября, 2020 11:45 дп
9 919 views
| Комментариев нет
LAMP Stack
Эта серия мануалов поможет вам предотвратить или устранить самые распространенные ошибки, которые возникают при работе с веб-сервером Apache.
Каждый мануал в этой серии включает описание распространенных ошибок Apache, связанных с конфигурацией, сетью, файловой системой или привилегиями.
Сообщение об ошибке Apache «AH00072: make_sock: could not bind to address» появляется, когда тот порт, который настроен для Apache, уже прослушивает другой процесс (Обычно это стандартный порт 80 для HTTP-соединений или порт 443 для HTTPS-соединений). Однако вызвать ошибку AH00072 может любой другой конфликт порта и процесса.
Ошибка возникает в сетевом стеке базовой операционной системы. Проблема заключается в том, что в любой момент времени к конкретному порту может быть привязан только один процесс. Если на прослушивание порта 80 настроен другой веб-сервер (допустим, Nginx) и он работает, то Apache не сможет запросить порт для себя.
Чтобы обнаружить конфликт порта Apache, вам необходимо изучить вывод systemctl и journalctl, чтобы определить IP-адрес и порт, вызывающие ошибку. Затем вы можете выбрать путь решения проблемы: переключить веб-серверы, изменить IP-адрес или порт для Apache (или подобрать комбинацию этих параметров).
Устранение ошибки с помощью systemctl
Следуя инструкциям по устранению неполадок из мануала Устранение общих ошибок Apache, первым делом мы должны проверить состояние Apache с помощью systemctl.
Если вывод systemctl не содержит данных, описывающих проблему, перейдите к последнему разделу этого руководства. В нем вы узнаете, как с помощью journalctl исследовать логи systemd, чтобы найти конфликтующий порт.
Команда systemctl status во многих случаях может предоставить всю диагностическую информацию, необходимую для устранения ошибки. Ее вывод укажет на IP-адрес, который использует Apache, а также на порт, к которому он пытается подключиться. Из этих выходных данных вы узнаете, как долго Apache не запускался (это поможет определить, как долго эта проблема мешает работе Apache) .
В дистрибутивах Ubuntu и Debian запустите следующую команду, чтобы проверить статус Apache:
sudo systemctl status apache2.service -l --no-pager
В системах CentOS и Fedora для проверки статуса Apache используйте эту команду:
sudo systemctl status httpd.service -l --no-pager
Флаг -l выводит все содержимое строки без сокращений (без замены длинных строк многоточием (…)). Флаг –no-pager выводит весь лог на ваш экран, не вызывая инструмент less, который показывает только один экран контента за раз.
Если у вас есть ошибка AH00072, вы должны получить подобный вывод:
httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Tue 2020-07-28 13:58:40 UTC; 8s ago
Docs: man:httpd.service(8)
Process: 69 ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND (code=exited, status=1/FAILURE)
Main PID: 69 (code=exited, status=1/FAILURE)
Status: "Reading configuration..."
Tasks: 213 (limit: 205060)
Memory: 25.9M
CGroup: /system.slice/containerd.service/system.slice/httpd.service
Jul 28 13:58:40 e3633cbfc65e systemd[1]: Starting The Apache HTTP Server…
Jul 28 13:58:40 e3633cbfc65e httpd[69]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jul 28 13:58:40 e3633cbfc65e httpd[69]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jul 28 13:58:40 e3633cbfc65e httpd[69]: no listening sockets available, shutting down
Jul 28 13:58:40 e3633cbfc65e httpd[69]: AH00015: Unable to open logs
Jul 28 13:58:40 e3633cbfc65e systemd[1]: httpd.service: Main process exited, code=exited, status=1/FAILURE
Jul 28 13:58:40 e3633cbfc65e systemd[1]: httpd.service: Failed with result 'exit-code'.
Jul 28 13:58:40 e3633cbfc65e systemd[1]: Failed to start The Apache HTTP Server.
Ваш вывод может немного отличаться, если вы используете дистрибутив Ubuntu или Debian (в них имя процесса Apache не httpd, а apache2).
Этот пример вывода systemctl содержит пару строк из лога systemd, описывающих ошибку AH00072 (они выделены красным). Эти строки, каждая из которых начинается с «(98)Address already in use: AH00072: make_sock: could not bind to address», предоставляют вам всю информацию об ошибке AH00072, которая необходима для дальнейшего ее устранения, поэтому вы можете пропустить следующий раздел мануала, посвященный работе с journalctl. Переходите сразу к разделу об утилитах ss и ps в конце этого руководства.
Если ваш вывод systemctl не показывает конкретной информации об IP-адресе и портах, которые вызывают ошибку AH00072, вам необходимо проверить вывод journalctl из логов systemd. В следующем разделе мы расскажем, как использовать journalctl для устранения ошибки AH00072.
Устранение ошибки с помощью логов journalctl
Если ваши выходные данные systemctl не содержат сведений об ошибке AH00072, вам следует продолжить поиски с помощью команды journalctl, которая предназначена для проверки логов systemd для Apache.
В системах, производных от Ubuntu и Debian, выполните следующую команду:
sudo journalctl -u apache2.service --since today --no-pager
В системах типа CentOS, Fedora и RedHat используйте эту команду:
sudo journalctl -u httpd.service --since today --no-pager
Флаг –since today ограничивает вывод команды только записями, созданными с 00:00:00 текущего дня. Использование этой опции поможет ограничить объем записей, которые вам необходимо изучить при поиске ошибок.
Если Apache не может подключиться к используемому порту, найдите в выходных данных следующие записи (в частности строки, содержащие код ошибки AH00072, как показано в этом примере):
-- Logs begin at Tue 2020-07-14 20:10:37 UTC, end at Tue 2020-07-28 14:01:40 UTC. --
. . .
Jul 28 14:03:01 b06f9c91975d apachectl[71]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Jul 28 14:03:01 b06f9c91975d apachectl[71]: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
Jul 28 14:03:01 b06f9c91975d apachectl[71]: no listening sockets available, shutting down
Эти выходные данные указывают на две ошибки AH00072. Первая строка объясняет, что Apache не может связаться с адресом [::]:80 (это порт 80 на всех доступных интерфейсах IPv6). Вторая строка с адресом 0.0.0.0:80 указывает, что Apache не может подключиться к порту 80 на всех доступных интерфейсах IPv4. В зависимости от конфигурации вашей системы IP-адреса могут отличаться, вывод может отображать только отдельные IP-адреса и включать только ошибки IPv4 или только IPv6.
Несмотря на то, что ваша система может иметь разные конфликтующие интерфейсы и порты, ваши ошибки будут похожи на показанный здесь вывод. Получив данные journalctl, вы сможете диагностировать проблему с помощью ss, о чем мы и поговорим в следующем разделе этого руководства.
Устранение ошибки с помощью утилит ss и ps
Чтобы устранить ошибку AH00072, вам необходимо определить, какой именно процесс прослушивает IP-адрес и порт, которые пытается использовать Apache. Большинство современных дистрибутивов Linux включают утилиту ss, которую можно использовать для сбора информации о состоянии сетевых сокетов системы.
В предыдущем разделе (о journalctl) вы видели, что какой-то процесс уже был привязан к адресам IPv4 и IPv6 на порту 80. Следующая команда определит имя процесса, который привязан к интерфейсу IPv4 на порту 80. Убедитесь, что вы заменили номер порта (если в вашем сообщении об ошибке указан другой порт, а не 80):
sudo ss -4 -tlnp | grep 80
Флаги команды ss изменяют ее стандартный вывод следующим образом:
- -4 запрашивает только информацию о сокетах, связанных с IPv4.
- -t ограничивает вывод только сокетами tcp.
- -l отображает все прослушивающие сокеты с учетом ограничений -4 и -t.
- -n отображает номера портов вместо имен протоколов типа «http» или «https». Это важно, поскольку Apache может пытаться подключиться к нестандартному порту, а имя сервиса будет сбивать с толку, в таком случае фактический номер порта удобнее.
- -p выводит информацию о процессе, который привязан к порту.
Запустив команду со всеми этими флагами, вы получите следующий вывод:
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=40,fd=6))
Первые три поля не важны для устранения ошибок AH00072, поэтому их можно игнорировать. Важными полями являются четвертое (0.0.0.0:80), которое соответствует обнаруженной ранее (с помощью journalctl) ошибке, а также последнее поле «users:((“nginx”,pid=40,fd=6))», в частности, фрагмент pid=40.
Если у вас есть ошибка AH00072, связанная с интерфейсом IPv6, повторите вызов ss, на этот раз используя флаг -6, чтобы ограничить интерфейсы IPv6:
sudo ss -6 -tlnp |grep 80
LISTEN 0 511 [::]:80 [::]:* users:(("nginx",pid=40,fd=7))
Убедитесь, что вы заменили номер порта (если в вашем сообщении об ошибке указан другой порт, а не 80).
Независимо от IPv4 и IPv6, выходные данные ss указывают, что программа с идентификатором процесса 40 (pid=40) привязана к интерфейсам 0.0.0.0:80 и [::]:80 соответственно. Этот процесс препятствует запуску Apache, поскольку он уже занимает необходимый порт. Чтобы определить имя программы, используйте утилиту ps, указав идентификатор процесса из вашего вывода вместо условного значения 40 в этом примере:
sudo ps -p 40
Вы получите похожий вывод:
PID TTY TIME CMD
40 ? 00:00:00 nginx
nginx – это имя процесса, который прослушивает нужные интерфейсы. Теперь, когда у вас есть имя программы, которая препятствует запуску Apache, вы можете решить, как устранить ошибку. Например, вы можете остановить процесс nginx, перенастроить его на другой интерфейс и порт или перенастроить Apache, чтобы избежать конфликта портов.
Обратите внимание: при поиске ошибки AH00072 в вашем случае это может быть не nginx, а другой процесс; порт и IP-адреса не обязательно будут 0.0.0.0 или [::], это может быть любой порт и адрес. Часто на одном сервере используются разные веб-серверы и прокси. Каждый может пытаться подключиться к разным портам IPv4 и интерфейсам IPv6 для обработки разного веб-трафика. Например, сервер, на котором настроен HAProxy, прослушивающий loopback адрес IPv4 (также называемый localhost) по порту 8080, будет отображаться в выводе ss следующим образом:
LISTEN 0 2000 127.0.0.1:8080 0.0.0.0:* users:(("haproxy",pid=545,fd=7))
Важно научиться объединять вывод systemctl или journalctl, который указывает определенные IP-адреса и порты, с диагностическими данными из ss, а затем и ps, чтобы сузить диапазон поиска и обнаружить процесс, который вызывает сбой Apache.
Заключение
В этом мануале вы узнали, как устранить ошибку Apache «AH00072 make_sock: could not bind to address» на интерфейсах IPv4 и IPv6. Вы также узнали, как использовать systemctl для проверки состояния сервера Apache, как с помощью journalctl изучить логи systemd на предмет конкретной информации об ошибке AH00072.
Собрав данные об ошибках, вы использовали утилиту ss для проверки состояния сетевых сокетов системы. После этого мы объединили информацию утилиты ss с утилитой ps, чтобы узнать имя процесса, из-за которого Apache не запускается.
Tags: Apache, journalctl, systemctl
-
Печать
-
E-mail
- 26 января 2023
-
Автор: Сергей Кузнецов
- Просмотров: 6884
Ошибка запуска сервиса 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 не было. Ничего, что бы на первый взгляд, могло повлиять на подобное поведение вроде тоже не было. Так что, это останется, наверное тайной, т.к. разбираться в этом нет ни какого желания.