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

CentOS 6.6 с Nginx 1.6.2 - внезапно не удается перезапустить nginx - nginx: сбой [Emerg] open () «/ usr / share / nginx / on» (13: разрешение отказано)

Это новая установка, в которой nginx ранее запускался и останавливался нормально. Я считаю, что эта ошибка возникла после того, как были успешно протестированы серверные блоки (nginx -t). Затем я попытался перезапустить nginx и получил эту ошибку:

nginx: [emerg] open() "/usr/share/nginx/on" failed (13: Permission denied)

Файл «on» не существовал до попытки перезапуска. Он только что был создан и пуст. Когда я перезапускаю php-fmp (успешно), а затем снова пытаюсь перезапустить nginx, ошибка меняется на:

nginx: [emerg] open() "/var/run/nginx.pid" failed (13: Permission denied)
nginx: configuration file /etc/nginx/nginx.conf test failed

Но опять же, когда я запускаю nginx -t, тест проходит успешно:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Я думал, что это проблема пользователя, но вроде все нормально:

# ps -elf | grep nginx
5 S nginx     2774  2773  0  80   0 - 234152 skb_re 22:07 ?       00:00:00 php-fpm: pool www
5 S nginx     2775  2773  0  80   0 - 234152 skb_re 22:07 ?       00:00:00 php-fpm: pool www
5 S nginx     2776  2773  0  80   0 - 234152 skb_re 22:07 ?       00:00:00 php-fpm: pool www
5 S nginx     2777  2773  0  80   0 - 234152 skb_re 22:07 ?       00:00:00 php-fpm: pool www
5 S nginx     2778  2773  0  80   0 - 234152 skb_re 22:07 ?       00:00:00 php-fpm: pool www
0 R root      2940  2472  0  80   0 - 25811 -      22:18 pts/0    00:00:00 grep nginx

Несмотря на то, что Nginx не запущен, файл nginx.pid остался, поэтому я удалил его. Это просто изменило сообщение об ошибке на:

nginx: [emerg] open() "/usr/share/nginx/on" failed (13: Permission denied) nginx: configuration file /etc/nginx/nginx.conf test failed.

Эта ошибка была получена независимо от того, как я пытался перезапустить систему, включая $ sudo /etc/init.d/nginx restart и $ sudo /etc/init.d/nginx reload. Я удалил пустой файл "on", что тоже не имело значения. Когда я использую $ getenforce, он возвращается Enforcing.

В ответ на @ ǝɲǝɲbρɯͽ:

sudo grep -vR '^$\|^\s*\#' /etc/nginx/conf.d/* | grep -v ";" и sudo grep -vR '^$\|^\s*\#' /etc/nginx/nginx.conf* | grep -v ";" пропущенных точек с запятой не было.

Команда sudo grep -ER "on|/usr/share" /etc/nginx/* распечатал почти каждую строку каждого файла в nginx, поэтому я не уверен, что я узнаю из этой информации. Кстати, /usr/shar/nginx содержит только этот пустой on файл, больше ничего.

sudo ausearch -m avc -ts recent -c nginx вернулся <no matches>

Излишне говорить, что я новичок в проблемах с сервером, но я подумал, что команда service --status-all (ниже) может дать полезную информацию. Конечно, мы уже знаем, что файл pid существует, даже если nginx мертв, но что за master (pid 1924) is running? Кроме того, есть ли что-нибудь в iptables, которое может нести ответственность за предотвращение перезапуска nginx?

atd (pid  1995) is running...
auditd (pid  1405) is running...
crond (pid  1982) is running...
htcacheclean is stopped

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all      ::/0                 ::/0                state RELATED,ESTABLISHED
2    ACCEPT     icmpv6    ::/0                 ::/0
3    ACCEPT     all      ::/0                 ::/0
4    ACCEPT     udp      ::/0                 fe80::/64           state NEW udp dpt:546
5    ACCEPT     tcp      ::/0                 ::/0                state NEW tcp dpt:22
6    REJECT     all      ::/0                 ::/0                reject-with icmp6-adm-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all      ::/0                 ::/0                reject-with icmp6-adm-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Table: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
5    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
6    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
7    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:3306
8    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:80

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

iscsi is stopped
iscsid is stopped
lvmetad is stopped
mdmonitor (pid  1445) is running...
multipathd is stopped
mysqld is stopped
netconsole module not loaded

Configured devices:
lo bond0 em1 em2

Currently active devices:
lo em1 em2 bond0

nginx dead but pid file exists
php-fpm is stopped
master (pid  1924) is running...
rdisc is stopped
restorecond is stopped
rsyslogd (pid  1425) is running...
sandbox is stopped
saslauthd is stopped
snmpd is stopped
snmptrapd is stopped
openssh-daemon (pid  1486) is running...
svnserve is stopped

/ usr / share / nginx / ... - это корневой веб-каталог по умолчанию; возможно, вы включили что-то и случайно коснулись этого файла. Поскольку ваш тест работает, он также может быть решен, но когда nginx дает сбой (или что-то вроде kill -9), он не избавляется от своего файла pid.

У меня нет опыта работы с php-fpm, но похоже, что ваш главный процесс nginx не работает. Вы можете точно проверить:

$ ps axu | grep `cat /var/run/nginx.pid`

Это обратные кавычки (`), а не апострофы ('). Если он не запущен, удалите файл pid:

$ sudo rm /var/run/nginx.pid

и перезапустите nginx. Во многих системах это:

$ sudo /etc/init.d/nginx restart

Вы не хотите делать это при нормальных обстоятельствах на действующем сайте. Есть способы получше, в том числе:

$ sudo /etc/init.d/nginx reload
изящные варианты управления

После перезапуска nginx вы должны увидеть что-то вроде этого:

$ ps axu | grep nginx

... worker threads
... 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf

Вы также можете:

$ /etc/init.d/nginx status

nginx (pid  1111) is running...

Изменить: диагностика из комментариев

1. Конфигурация

Очень внимательно посмотрите на свои изменения. Когда дело доходит до отсутствия точек с запятой, у nginx нет проблем. Почти каждая строка должна заканчиваться на;
- Если вы что-то пропустили, nginx обработает дополнительные строки, как если бы они были частью одной директивы. Например (а это может быть хуже этого) эти две строки обрабатываются как одна и та же директива: root /var/nginx/..... # no semicolon sendfile on;
- Nginx не обязан быть для вас действительно хорошим средством проверки синтаксиса, поэтому нет гарантии, что nginx обнаружит эту ошибку перед попыткой запустить рабочие процессы, когда SELinux (правильно) наступает на аномальное действие процесса.

Чтобы упростить поиск этих строк¹:

$ sudo grep -vR '^$\|^\s*\#' /etc/nginx/conf.d/* | grep -v ";"

Или строки с «on» или «/ usr / share»:

$ sudo grep -ER "on|/usr/share" /etc/nginx/conf.d/*

Вероятно, вам нужно исправить один из них (не добавляйте точки с запятой в строки {}), а затем:

$ sudo rm /usr/share/nginx/on /var/run/nginx.pid
$ sudo /etc/init.d/nginx restart

2. Метаданные: Подтвердите участие SELinux (или нет)

Это только для информации. Он постоянно появляется в редактировании и является стержнем для нас / будущих посетителей. Предполагая, что nginx все еще не работает (вы не исправили конфигурацию):

$ sudo /etc/init.d/nginx start
$ sudo ausearch -m avc -ts recent -c nginx

Хотя мы фильтруем nginx (могут быть и другие отказы), SELinux, вероятно, не отображается, если вы видите:

<no matches>

SELinux обозначается AVC, подобным:

type=AVC msg=audit(timestamp:123): avc:  denied  { getattr } for  pid=1234 comm="nginx" path="/usr/share/nginx/on" dev=sda ino=123456 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:var_t:s0 tclass=file

Проблема в том, что в какой-то момент во время запуска файл создается в другом контексте, чем nginx, или его рабочие процессы (которые переключают контексты безопасности) по праву не могут касаться. По назначению контексты видны путем добавления -Z ко многим командам, фиксируемого с помощью chcon (изменение контекста). легко найти.

¹ grep кредит

У вас есть свойство, которое ожидает путь, но имеет логическое значение, например

access_log on;

access_log ожидает путь, но ему предоставляется логическое значение on. В этом можно убедиться, внимательно прочитав ошибку:

nginx: [emerg] open() "/usr/share/nginx/on" failed (13: Permission denied)

Обратите внимание на on относительно вашего базового пути nginx.

CentOS 6.6 с Nginx 1.6.2 - внезапно не удается перезапустить nginx - nginx: сбой [Emerg] open () «/ usr / share / nginx / on» (13: разрешение отказано)

В ответ на @ ǝɲǝɲbρɯͽ:

** Изменить: диагностика из комментариев **

1. Конфигурация

2. Метаданные: Подтвердите участие SELinux (или нет)

Изменить: диагностика из комментариев