/ usr / share / nginx / ... é onde está a webroot padrão; você pode ter definido algo para estar "ligado" e acidentalmente tocou esse arquivo. Como o seu teste funciona, ele também pode ter sido resolvido, mas quando o nginx falha (ou coisas como kill -9) ele não se livra do arquivo pid.
Eu não tenho experiência com o php-fpm, mas parece que o seu processo mestre nginx não está sendo executado. Você pode verificar com certeza por:
$ ps axu | grep 'cat /var/run/nginx.pid'
Esses são backticks (') e não apóstrofos ('). Se não estiver em execução, remova o arquivo pid:
$ sudo rm /var/run/nginx.pid
e reinicie o nginx. Em muitos sistemas, isso é:
$ sudo /etc/init.d/nginx restart
Você não quer fazer isso em circunstâncias normais em um site ativo. Existem maneiras melhores, incluindo:
- $ sudo /etc/init.d/nginx recarregar
- opções de controle elegantes
Depois de reiniciar o nginx, você verá algo assim:
$ ps axu | grep nginx
... worker threads
... 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
Você também pode:
$ /etc/init.d/nginx status
nginx (pid 1111) is running...
** Editar: diagnóstico dos comentários **
1. Configuração
- Observe com muito cuidado suas alterações. O nginx é frágil quando se trata de perder ponto e vírgula. Quase toda linha deve terminar com;
- Se você perdeu algum, o nginx processará linhas adicionais como se fossem parte da mesma diretiva. Por exemplo (e pode ser pior que isso) essas duas linhas são processadas como a mesma diretiva: %código%
- Não é responsabilidade do nginx ser um verificador de sintaxe muito bom para você, portanto não há garantia de que o nginx detectará esse erro antes de tentar iniciar os trabalhadores, onde o SELinux (corretamente) pisa na ação anômala do processo.
Para facilitar a localização dessas linhas¹:
$ sudo grep -vR '^$\|^\s*\#' /etc/nginx/conf.d/* | grep -v ";"
Ou linhas com "on" ou "/ usr / share":
$ sudo grep -ER "on|/usr/share" /etc/nginx/conf.d/*
Você provavelmente precisará consertar um desses (não adicione ponto-e-vírgulas a {} linhas) e, em seguida:
$ sudo rm /usr/share/nginx/on /var/run/nginx.pid
$ sudo /etc/init.d/nginx restart
2. Metadados: Comprove o envolvimento do SELinux (ou não)
Isto é apenas para informação. Ela surge o tempo todo em edições e é um ponto de partida para nós / futuros visitantes. Assumindo que o nginx ainda está quebrado (você não corrigiu a configuração):
$ sudo /etc/init.d/nginx start
$ sudo ausearch -m avc -ts recent -c nginx
Apesar de estarmos filtrando o nginx (pode haver outras negações), o SELinux provavelmente não é indicado se você vir:
<no matches>
SELinux é indicado com AVCs semelhantes a:
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
O problema é que, em algum momento durante a inicialização, um arquivo é criado em um contexto diferente do nginx ou seus trabalhadores (que alternam contextos de segurança) não têm permissão para tocar. Quando pretendido, os contextos são visíveis adicionando -Z a muitos comandos, fixados com chcon (contexto de alteração) e as questões em torno disso são facilmente encontradas .