PHP-FPM Script principal desconhecido, mas SCRIPT_FILENAME está definido corretamente [duplicado]

2

Estou usando o Nginx 1.5.12.1 com PHP-FPM para PHP 5.6.5 no CentOS 6.6 x64. Quando eu visito qualquer página, recebo um erro 404:

File not found.

Meu log de erros do PHP-FPM não diz nada de útil, mas meu log de erros do Nginx:

2015/04/02 10:25:44 [error] 24689#0: *35 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 172.31.42.64, server: _, request: "GET /_index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.dev.example.com"

Neste ponto, provavelmente você está pensando que SCRIPT_FILENAME está configurado incorretamente. Não é, ou pelo menos parece correto para mim. Se eu acionar um sniffer de pacotes e cavar a conexão entre Nginx e PHP-FPM, eu posso ver que as variáveis estão definidas corretamente:

  • SCRIPT_FILENAME é /opt/example/_index.php
  • SCRIPT_NAME é /_index.php
  • DOCUMENT_ROOT é /opt/example
  • REQUEST_URI é /_index.php
  • DOCUMENT_URI é /_index.php

O script está realmente localizado em /opt/example/_index.php e a raiz do documento é /opt/example . Você vê algo de errado com essas variáveis, como foi passado para o PHP-FPM?

Supondo que eles estejam corretos, imaginei que o PHP-FPM não tivesse acesso aos arquivos. Eu configurei tudo para 777 , incluindo todo o diretório example . Isso não resolveu o problema.

Quais são alguns outros motivos pelos quais o PHP-FPM retornaria "Script primário desconhecido"? Como posso depurar ainda mais a situação? Existem outras permissões que o PHP-FPM precisa fazer para funcionar?

Edit: Descobri que, se eu executo o PHP-FPM como root, meu problema é resolvido, então isso vai ser algum tipo de problema de permissões, mas eu não sei o que os scripts e diretórios nos quais eles estão estão abertos.

    
por Brad 02.04.2015 / 17:36

1 resposta

1

O SELinux foi ativado e impedindo todo o acesso ao sistema de arquivos para o usuário que o PHP-FPM estava executando. Mudar isso resolveu o problema.

Isso ficou visível verificando /var/log/audit/audit.log como sugerido nos comentários de Michael Hampton.

    
por 02.04.2015 / 20:28

Tags