Apache 2.4 Evento MPM + php-fpm + php-opcache produz erros de “Conexão redefinida por peer”

Question

Eu tenho um servidor CentOS 7 rodando o Apache 2.4.6 com o Event MPM e o php-fpm versão 5.6.10 (do repositório REMI). Aqui está a configuração relevante do Apache para enviar solicitações para o php-fpm dentro do vhost (é o único site neste servidor):

<FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php-fpm/www.sock|fcgi://localhost"
</FilesMatch>

Aqui está o conf do pool php-fpm:

listen = /var/run/php-fpm/www.sock
listen.owner = apache
listen.group = apache
pm = static
pm.max_children = 50
pm.max_requests = 0

Aqui está a configuração do php-opcache (a configuração de instalação padrão):

zend_extension=opcache.so
opcache.enable=1
opcache.memory_consumption=128
opcache.max_accelerated_files=4000
opcache.blacklist_filename=/etc/php.d/opcache*.blacklist

Meu problema: Sempre que eu instalo e ativo o php-opcache, os seguintes erros começam a aparecer no meu log de erros:

[Thu Jun 18 08:10:58.499871 2015] [mpm_event:debug] [pid 16546:tid 139798115227392] event.c(986): (104)Connection reset by peer: [client 157.55.39.233:15962] AH00470: network write failure in core output filter
[Thu Jun 18 08:10:58.527424 2015] [mpm_event:debug] [pid 16546:tid 139797922195200] event.c(986): (103)Software caused connection abort: [client 157.55.39.233:15990] AH00470: network write failure in core output filter

Se eu remover o php-opcache, os erros cessarão. Os usuários estão relatando um erro 502 Serviço Indisponível no frontend sempre que isso ocorre.

Eu literalmente passei pelo menos 6 horas tentando o Google e encontrando soluções. Alguém disse que a opção fastshutdown do opcache era um problema, mas está desativada na configuração padrão. Alterei o método de gerenciamento de processo php-fpm para estático sem reciclagem (max_requests = 0), mas isso também não mudou nada. Eu também tentei usar o método de proxy TCP com o Apache (em vez de sockets), e isso também não teve efeito.

Não tenho certeza se isso é relevante ou não, mas independentemente de o php-opcache estar instalado ou não, recebo os seguintes erros no log de erros (mas com uma frequência muito menor, < 0,5% de todos tráfego, que pode ser uma questão separada):

[Thu Jun 18 08:32:37.223430 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] [client 37.46.115.238:55624] AH01068: Got bogus version 10, referer: ...
[Thu Jun 18 08:32:37.223462 2015] [proxy_fcgi:error] [pid 19187:tid 140598765840128] (22)Invalid argument: [client 37.46.115.238:55624] AH01075: Error dispatching request to :, referer: ...

Esse problema é muito semelhante a este , embora essa pessoa esteja usando ProxyPassMatch com o método TCP, o que eu não sou (porque ignora o .htaccess).

Alguém tem alguma ideia que eu já não tenha mencionado?

    

Answer 1

Quando vejo problemas semelhantes em nossos ambientes, parece que isso ocorre devido à maneira como o OpCache (por padrão) compartilha um único cache entre todos os usuários em um ambiente de hospedagem compartilhada. Um bug foi enviado (e você pode, e deve, ir votar para informar aos mantenedores como importante, isso pode ser para o seu caso de uso), embora nenhum compromisso tenha sido feito na entrega de uma correção.

TL; DR: Por padrão, quando o OpCache está habilitado, o cache usado para armazenar códigos de bytes compilados é compartilhado entre todos os usuários. Em um ambiente onde a hospedagem é compartilhada entre vários sites / usuários, isso pode resultar em um site que captura a saída em cache do php scripts de outro site ou, se configurações de segurança específicas estiverem habilitadas, mesmo gerando erros .

If you plan on using PHP-FPM with PHP 5.5+'s built in opcache, please read the blog post below before you actually do that. Turns out that the opcode cache can be read by any user on the server. This means that if there are say, 10 separate users, with their own vhosts and directories, and you configure one PHP-FPM pool per user, each user can still see what scripts are cached and their locations. Since they have read access to the cache they could potentially view all this data.

This is obviously a massive security concern, and even if no one exploits this, there is still a chance of scripts being read by the wrong user when generating a page, so websites could possibly be displaying the wrong data / info if there are multiple index.php scripts in the cache.

Embora nenhuma correção tenha sido lançada oficialmente, se você estiver usando o cPanel, este wiki tem uma maneira documentada de configurar o php-fpm pools a serem criados e protegidos por usuário e se você seguir as instruções abaixo, bem como as OBSERVAÇÕES IMPORTANTES na parte inferior desta resposta, deve ser capaz de obter a funcionalidade desejada sem erros

Essa postagem também documenta como você pode configurar isso manualmente por site / por usuário (embora eu possa apostar que isso pode se tornar tedioso se você estiver hospedando muitos sites). Se você não estiver usando o cPanel, pode ser necessário modificar os scripts para especificar seus caminhos individuais e nomes de usuários, em vez das variáveis que estão sendo usadas pelo mecanismo de configuração do cPanel.

NOTAS IMPORTANTES

Durante os testes e pesquisas adicionais, deparei-me com este artigo, que fornece alguns esclarecimentos que podem ser relevantes para o seu caso específico. situação:

1. É necessário certificar-se de que o parâmetro opcache.use_cwd esteja definido como true para a configuração do OpCache do seu aplicativo - ele é definido como false por padrão e deixá-lo definido como padrão provavelmente causará colisões se você estiver hospedando mais de uma aplicação PHP no seu sistema:

First of all, probably in each typical project you will have to ensure that the opcache.use_cwd option is set to true. Enabling this setting means that the OpCache engine will look at the full file paths to distinguish between files with the same names. Setting it to false will lead to collisions between files with the same base name.

2. Se você estiver executando um aplicativo desenvolvido pelo Zend Framework ou outra estrutura semelhante que faça uso de anotações, você TAMBÉM precisará garantir que as diretivas opcache.load_comments e opcache.save_comments estejam definidas como true . Você deve verificar essa sugestão com sua documentação de aplicativo / estrutura, pois a maioria já atualizou seus documentos com instruções específicas sobre como ativar o uso do OpCache adequadamente para seus sistemas:

There is also a setting that is important in tools and frameworks that make use of annotations. If you use Doctrine, Zend Framework 2 or PHP Unit, remember to set the opcache.load_comments and opcache.save_comments settings to true. In result, the documentation comments from your files will also be included in the precompiled code generated by OpCache. This setting will allow you to work with annotations without any disruptions.

If your project is based on a specific framework or a web application, it’s always a good idea to check the documentation for any guidelines regarding the OpCache configuration

NOTAS IMPORTANTES

Espero que isso tenha ajudado - e se você estiver usando o cPanel, deixe um comentário para nos informar como você lidou com essa parte da configuração! Veja também esta pergunta & comentários associados .