Ligar para a function indefinida pcntl_fork () php-fpm nginx

Estou tentando usar o pcntl_fork() no php-fpm, mas não está disponível e recebo:

 Call to undefined function pcntl_fork() 

Mesmo que eu tenha comentado as disable_functions no php.ini . phpinfo() mostra o autor e php -m também lista pcntl . Se eu estiver executando meu script do cli, isso funciona. Existe alguma outra opção que eu preciso para ativar?

Como MWE preparei um ambiente docker mínimo em https://github.com/white-gecko/pcntl-mwe resp.

 docker pull whitegecko/pcntl-mwe 

se você executá-lo com docker run -it --rm --name pcntl -p 8080:80 pcntl você terá o exemplo em http://localhost:8080/ e phpinfo em http://localhost:8080/phpinfo.php . É um sistema debian jessie.

A extensão PCNTL deve ser restrita a operar somente na CLI; Você não pode usá-lo em outros ambientes de servidor (fpm, mod_php, etc.).

O que é suposto acontecer é que as extensões marcadas como “cli” só devem ser vinculadas de forma estática ao binário CLI, ou permitir carregar compartilhado na CLI e omitidas de compilações compartilhadas que visam outros SAPIs (libphp7.so).

O arquivo autoconf (ext / pcntl / config.m4) que configura PCNTL para PHP deve instruir o processo de compilation para desativar o carregamento de PCNTL em outros SAPIS, acontece que 1) não é muito bom e 2) isso não foi levado em consideração quando o FPM foi incorporado ao PHP: para que a FPM ignore e ligue com a fonte PCNTL de qualquer maneira (se a extensão for ativada no tempo de compilation), e outros SAPIs permitirão que você carregue a biblioteca se ela for compartilhada porque o DSO (compartilhado biblioteca) não impõe a restrição SAPI. Nenhuma dessas coisas (vinculação de FPM e outros carregando) deve ser permitida, e é uma idéia terrível forçar um SAPI não suportado a carregar o PCNTL.

Quando você fork um processo, você cria um clone de cópia-em-gravação do processo que chamou fork: Dentro do Apache ou FPM isso significa que o arquivo duplicado (socket) lida com o qual você não pode gerenciar graciosamente no processo filho (para você não tem access a eles a partir do PHP).

O motivo pelo qual este deveria ser restrito à CLI (e CGI precoce) é que esses SAPIs usam um único modelo de processo. Embora o FPM seja tecnicamente uma interface CGI, certamente não é um processo único e, portanto, nunca será um ambiente adequado para se abaixar em terra do usuário.