nginx error_log сообщает «сбой bind () до 0.0.0.0:80 (48: адрес уже используется)»

При поиске решения несколько мест, таких как вот этот говорят, что решение состоит в том, чтобы удалить / закомментировать listen директивная строка в хосте по умолчанию.

#listen       80 default_server;

Для меня это ничего не изменило, и основной error_log продолжал заполняться.

Наконец кто-то в форумы nginx устранение аналогичной проблемы рекомендуется посмотреть на вывод

ps ax -o pid,ppid,%cpu,vsz,wchan,command|egrep '(nginx|PID)'

Что для меня было

  PID  PPID  %CPU      VSZ WCHAN  COMMAND
 4963     1   0.0  2504128 -      /opt/local/bin/daemondo --label=nginx --start-cmd /opt/local/sbin/nginx ; --pid=fileauto --pidfile /opt/local/var/run/nginx/nginx.pid
 4967     1   0.0  2475388 -      nginx: master process /opt/local/sbin/nginx
 4969  4967   0.0  2476412 -      nginx: worker process
 5024  1538   0.0  2432784 -      egrep (nginx|PID)
 1969  1874   0.0  2432772 -      tail -F /opt/local/etc/nginx/logs/error.log

В первой строке я заметил, что расположение pidfile задано в команде запуска MacPorts --pidfile /opt/local/var/run/nginx/nginx.pid и что оно отличалось от того места, которое я указал в моем nginx.conf. Я изменил pid запись обратно, чтобы соответствовать тому, что указывала команда запуска:

pid        /opt/local/var/run/nginx/nginx.pid;

После перезапуска nginx и закрытия error_log (tail -F /opt/local/etc/nginx/logs/error.log) Я заметил, что проблема решена.

Вкратце: если вы используете версию nginx для MacPorts, вы, вероятно, не захотите связываться с изменением местоположения pidfile.

Кроме того, если вы посмотрите на другие страницы, пытающиеся решить эту проблему, в частности те, на которых проблема была устранена путем удаления listen или если что-то еще, например Apache, также использует порт 80, вы заметите, что в этих журналах ошибок написано

[emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

и у меня был

[emerg] bind() to 0.0.0.0:80 failed (48: Address already in use)

Я подозреваю разницу между ошибкой 98 и ошибка 48 это разница, но я не смог найти описания различных ошибок.

У меня была похожая проблема с установкой Nginx Homebrew. У меня была более старая установка Nginx, работающая как процесс launchd, хотя я удалил ее некоторое время назад (возможно, я не lauchctl unload он или Homebrew не отключили его при удалении). Во всяком случае, Nginx не подошел бы brew list ни netstat может найти процесс, используя порт. Я мог обнаружить это только с lsof:

sudo lsof -i 4tcp:8080

Процесс был запущен и использовал порт, но я нигде не мог его найти (я даже пытался sudo find / -name nginx -type d чтобы найти на всем диске каталоги с именем nginx, но безуспешно). После некоторого удара головой о стол я подумал о том, чтобы проверить, показывает ли Activity Monitor путь к открытым файлам для процесса, и это действительно так.

Откройте Activity Monitor, найдите процесс, дважды щелкните его, и откроется другое окно с деталями процесса:

Несмотря на то, что процесс и его файлы были указаны в списке, файлов на диске не было. Мне просто пришлось принудительно закрыть запущенные процессы зомби Nginx, а затем новая установка Nginx заработала, как ожидалось.

Я не уверен, но если я правильно помню, я также пытался ps aux | grep nginx и он не появился, но выстрел стоит:

sudo ps aux | grep nginx