nginx error_log отчеты “связывают () с 0.0.0.0:80 отказавший (48: Адрес, уже используемый)”
Можно выполнить "prctl $$" для проверки пределов текущего процесса. "Системные" являются максимумом, который может быть установлен, привилегированный требует, чтобы привилегированный пользователь изменился, и основной может быть изменен любым. Тот, который относится к текущему процессу, является самым низким и будет наверху списка. Например, если я делаю это для изменения моих дескрипторов файлов на 100 000:
prctl -t basic -n process.max-file-descriptor -v 100000 $$
Теперь, если я выполняю "prctl $$" снова, привилегированное значение теперь наверху, потому что это является самым низким. Даже при том, что я изменил основные настройки, они не могут дать мне больше ресурсов, чем привилегированное значение.
Как уже был отмечен, Солярис очень гибкий и динамичным на пределах ресурса, и они могут присвоенный процессом, задачей, проектом и зоной. Вы видите, к которому это относится на имя ресурса. Я не думаю, что существует Linux, эквивалентный из проектов и зон. Задачи в основном эквивалентны для обработки групп. Так как Вы, вероятно, выполняете все в конфигурации по умолчанию и глобальной зоне, команда prctl на Вашем текущем процессе, вероятно, достаточно хороша, какой Вы просите.
Я должен также упомянуть действие, поскольку это может быть импортом в Вас. Превышение ресурса может возвратить ошибку коду, который это просит (отклонять), отправлять сигналу в процесс (сигнал), или ничего не делает (ни один) в случае, если Вы просто хотите зарегистрировать его, но не повредить что-либо.
При поиске решения в нескольких местах, таких как этот , говорят, что решение состоит в том, чтобы удалить / закомментировать строку директивы 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 обратно, чтобы она соответствовала тому, что указывала команда запуска:
У меня была аналогичная проблема с установкой Nginx Homebrew. У меня была более старая установка Nginx, работающая как процесс launchd, хотя я удалил ее некоторое время назад (возможно, я не lauchctl выгрузил ее, или Homebrew не отключил ее при удалении). В любом случае ни Nginx не попадал в список пивоварения , ни netstat не мог найти процесс, использующий порт. Я мог обнаружить это только с помощью lsof :
sudo lsof -i 4tcp:8080
Процесс работал и использовал порт, но я нигде не мог его найти (я даже пытался sudo find / -name nginx -type d для поиска на всем диске каталогов с именем nginx, но безуспешно). После некоторого удара головой о стол я подумал о том, чтобы проверить, показывает ли Activity Monitor путь к открытым файлам для процесса, и это действительно так.
Откройте Activity Monitor, найдите процесс, дважды щелкните по нему, и он откроется другое окно с подробностями процесса:
Несмотря на то, что процесс и его файлы были перечислены, файлы не существовали на диске. Мне просто пришлось принудительно закрыть запущенные процессы Zombie Nginx, а затем новая установка Nginx заработала, как ожидалось.
Я не уверен, но если я правильно помню, я также попытался ps aux | grep nginx , и он не появился, но попытка того стоит:
sudo ps aux | grep nginx