Início / server / Perguntas / 977936
Accepted
Machavity
Asked: 2019-08-05 15:33:26 +0800 CST

PHP-FPM + nginx produzindo uma permissão negada, mas apenas em certas páginas grandes

  • 772

Eu tenho uma instância do AWS Lightsail (instância de 1 GB de RAM) executando um site relativamente novo (ou seja, praticamente sem tráfego). Está rodando nginx e PHP-FPM 7.3 (tentei com 7.2 também) e MariaDB. Tudo isso está sob o CentOS 7.

Tudo funcionou bem no nível gratuito da AWS. Executei uma instância T2.micro EC2 e uma instância T2.micro RDS. Lightsail tem sido um pouco... mais sensível. Para fazer o Lightsail funcionar, troquei o PHP-FPM paraondemand

ondemand - nenhum filho é criado na inicialização. As crianças serão bifurcadas quando novas solicitações forem conectadas.

Eu tive que fazer isso, ou o MariaDB travaria aleatoriamente. Isso não parece afetar o problema abaixo.

O painel de administração do Wordpress parou de funcionar corretamente e todos disseram para CONCATENATE_SCRIPTSdesligar. Isso funciona... principalmente. O editor de postagens e modelos está com problemas. Ninguém foi capaz de me dar uma pista do porquê. Olhando ao redor, eu encontrei algo eu mesmo.

As páginas que não funcionam não estão carregando completamente. Com CONCATENATE_SCRIPTSa ativação, os arquivos CSS são carregados em uma página gigante. Como isso não é renderizado completamente, os arquivos CSS e JS são ignorados pelo navegador. CONCATENATE_SCRIPTScontorna isso simplesmente dividindo-os em arquivos componentes, que são menores e carregam facilmente. Mas a página de edição não pode ser dividida e depurar o problema subjacente tem sido enlouquecedor. Eu recebo uma resposta de 200 e alguns dados

A página retorna 200

Mas o desenho da página está incompleto. Eu diria que talvez 80-90% do HTML esteja lá, mas corte. Na seção começando aqui (bloco JS)

wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( {"\/":{"body":{"name":"S

ele apenas termina abruptamente, e no mesmo ponto todas as vezes. É como se o PHP-FPM ou o nginx tivessem parado, mas sem nenhum log de erro (e a maioria dos outros problemas por aí sobre esse tipo de configuração são para páginas que não desenham). Ainda mais estranho é que não está fazendo isso em páginas menores, apenas muito longas. Não há tempo de roubo tope a instância não parece estar sob nenhuma carga séria, então não sei por que faria isso. Recarreguei todos os arquivos novos e até configurei um site WP separado para testar isso e todos o fazem.

Por comentários, ativei o log de depuração do nginx e encontrei

2019/08/07 02:33:08 [crit] 1461#0: *47 open() "/var/lib/nginx/tmp/fastcgi/3/00/0000000003" failed (13: Permission denied) while reading upstream, client: x.x.x.x, server: example.com, request: "GET /wp-admin/post-new.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000",

Isso não faz sentido porque ele faria isso em APENAS um punhado de arquivos grandes. Nenhuma unidade está cheia ou perto disso. Eu li esta pergunta, mas tanto o nginx quanto o PHP-FPM estão sendo executados no apache. A exclusão dos arquivos tmp também não resolveu. Os diretórios são de propriedade de apache:root, mas alterá-los para apache:apachenão tem efeito. O SELinux também não parece ser o culpado. Também não estou usando proxy_cache.

nginx

1 respostas

  1. Best Answer

    Em primeiro lugar, a falha está relacionada ao buffer FastCGI , em vez do cache de proxy.

    Isso é óbvio de /var/lib/nginx/tmp/fastcgi....

    Por que você experimenta um erro apenas em páginas particularmente grandes: se seus buffers FastCGI configurados não forem suficientes para ajustar toda a resposta do PHP-FPM na memória, e isso acontecerá com mais frequência com respostas grandes, é claro , o NGINX tentará escrever partes de a resposta aos arquivos temporários.

    E aparentemente, as permissões no diretório para armazenar arquivos temporários FastCGI não permitem que o NGINX salve arquivos lá, portanto, ele falha exatamente em determinado ponto quando a resposta é "muito grande".

    O caminho também indica que você não está usando uma distribuição oficial do NGINX /var/lib/nginx/tmp/fastcgi, porque, se o fizesse, acabaria com o ./var/cache/nginx/fastcgi_tempnginx:root

    Eu sugeriria usar estoque, distribuição oficial do NGINX.

    mas tanto o nginx quanto o PHP-FPM estão sendo executados no apache

    Off-topic, mas: Esta é uma configuração incorreta de qualquer maneira. A configuração correta está executando o NGINX como um usuário (seja ele apache, nginxou qualquer outra coisa), enquanto o pool PHP-FPM do seu aplicativo é executado sob seu próprio usuário, por exemplo foo. Em seguida, torne seu nginxusuário membro do foogrupo. Não há desculpa para executar tudo em um único usuário só porque você tem apenas um aplicativo em um determinado servidor.

    De qualquer forma, trate-o como um chmodproblema típico:

    • Verifique com qual processo de trabalho do usuário NGINX é executado ( userdiretiva em sua configuração)
    • Tente listar os arquivos do diretório em questão usando esse usuário, de cima para baixo, até encontrar o local onde ele para de funcionar e, em seguida, corrija as permissões recursivamente.

    Exemplo, digamos que seu processo de trabalho NGINX seja, de fato, como você disse, executado pelo apacheusuário e não possa acessar /var/lib/nginx/tmp/fastcgi:

    sudo -u apache ls /var/

    Isso funcionou? As permissões estão corretas, você pode acessar esse diretório por meio do usuário do processo de trabalho do NGINX. É importante entender que você precisa ser capaz de percorrer (como na rxpermissão) para todos os diretórios superiores para poder ler o conteúdo de qualquer diretório abaixo. Ou seja, para o nosso "destino final", que é /var/lib/nginx/tmp/fastcgi, precisamos conseguir ler tudo de /var, /var/lib, etc.

    Se a leitura /varnão funcionar (embora indique um tipo de sistema corrompido), você precisa permitir que "outros" a leiam, por exemplochmod o+rX /var

    sudo -u apache ls /var/lib

    Isto funciona? Permissões para /var/lib são boas. Se não, você precisa deixar que outros leiam:chmod o+rX /var/lib

    sudo -u apache ls /var/lib/nginx

    Isto funciona? Caso contrário, verifique a propriedade e as permissões via stat. Em seguida, certifique-se de que o usuário NGINX seja o proprietário do diretório /var/lib/nginxe que chmod(desta vez, para "proprietário") permita que ele percorra o diretório:

    chown apache:root /var/lib/nginx
chmod u+rX /var/lib/nginx

    Certifique-se de que o mesmo (de propriedade do usuário do NGINX, possa ser lido (percorrido) por ele) para/var/lib/nginx/tmp

    E, finalmente /var/lib/nginx/tmp/fastcgi, você precisará que o usuário do NGINX seja capaz de executar todas as leituras, execução (transversal para) e gravação:

    chown apache:root /var/lib/nginx/tmp/fastcgi 
chmod 0700 /var/lib/nginx/tmp/fastcgi

    Então, basicamente, é uma operação repetida de enxágue enquanto percorre os arquivos relevantes até que funcione.

    Verifique se tudo está configurado corretamente, tentando listar o conteúdo do diretório e criando arquivos nele:

    sudo -u apache ls /var/lib/nginx/tmp/fastcgi
sudo -u apache touch /var/lib/nginx/tmp/fastcgi/test.txt
    • 6

relate perguntas