pode ou não funcionar, parece altamente improvável, mas alguém teve um problema semelhante, e essa foi a solução;
chmod 755 /var/log/httpd/ ou qualquer que seja o diretório dos registros do apache, no seu servidor.
Atualizei recentemente meu servidor Apache2 e agora não consigo executar um aplicativo CGI. Meus logs estão sendo exibidos
(13) Permissão negada incapaz de se conectar ao cgi deamon após várias tentativas
Eu entendo que a mensagem de erro significa que o Apache está sendo negado alguma permissão para algum arquivo, e estou perplexo sobre como rastrear e resolver o problema.
O arquivo mencionado na mensagem de erro é realmente o arquivo bloqueado? Ou o problema pode ser causado por algum outro arquivo necessário? O arquivo .cgi está onde sempre esteve, sob / usr / share. A propriedade do arquivo (raiz) e as permissões (legível / executável pelo mundo) são as mesmas que sempre foram para o arquivo e seus antepassados. Os rótulos do arquivo SELinux permanecem inalterados.
O log de auditoria do SELinux não mostra nenhuma negação associada ao Apache nem ao programa CGI. No caso de uma condição donotaudit, eu habilitei a auditoria, mas ainda não vi nada. Eu mudei o SELinux para o modo permissivo brevemente, sem sucesso. Eu até tentei reiniciar o Apache enquanto estava no modo permissivo. Isso não resolveu o problema.
Alguma sugestão sobre como resolver este problema? Estou tentado a reverter para o Apache mais antigo.
pode ou não funcionar, parece altamente improvável, mas alguém teve um problema semelhante, e essa foi a solução;
chmod 755 /var/log/httpd/ ou qualquer que seja o diretório dos registros do apache, no seu servidor.
Embora esta seja uma pergunta antiga, pensei em acrescentar minha resposta, pois tive pouco sucesso em encontrar uma explicação ou solução adequada na Internet.
Eu tive esse problema ocorrer no RHEL 7 com o Apache 2.4 (instalado como o pacote httpd24) somente ao usar o evento MPM (o MPM prefork funcionou bem). O SELinux já estava definido como permissivo.
Com base no comentário sobre os sockets CGI, verifiquei a documentação:
Essencialmente, o daemon CGI ao usar o mpm-event requer um arquivo de soquete. Como o Apache é executado sob o apache do usuário e o apache do grupo no meu servidor (e sem dúvida muitos outros), a pasta que contém esse arquivo de soquete deve ter acesso de leitura / gravação pelo apache.apache.
Não querendo substituir as permissões da pasta de log, optei por definir explicitamente a diretiva ScriptSock em conf.modules.d/00-mpm.conf :
ScriptSock /var/run/httpd/cgid.sock
Assegurei então que o diretório httpd existia (note que você precisa configurar isso via tmpfiles.d , pois /var/run é um tmpfs) e alterou a propriedade para apache.apache. As permissões foram deixadas como o 755 padrão.
Isso resolveu o problema para mim.
Eu tive alterações no comportamento do módulo nas atualizações do apache. É possível que as diretivas do apache conf possam precisar de algumas alterações para servir adequadamente o seu cgi. Sem saber o conf do apache e os detalhes do cgi e sua localização no sistema de arquivos, é realmente difícil fazer mais do que apenas especular.
Além disso, se você suspeitar do SELinux, tente desabilitá-lo para ver se o apache começa a servir o CGI novamente. Se isso acontecer, você pode começar a concentrar seus esforços em ajustar a política para permitir o que está tentando fazer ou colocar seu sistema em conformidade com a política do SELinux.
O AIX 7 teve o mesmo problema. definir permissões no diretório / var / log / httpd para corrigir.
O erro não é específico para nenhum arquivo ou diretório específico. Este é o padrão de erro, que não contém pistas sobre qual permissão é a causa raiz.
... [cgid:error] ... (13)Permission denied: ... AH01257: unable to connect to cgi daemon after multiple tries: ... referer: ...
Se o padrão acima aparecer nas entradas de log do httpd, mas os logs de auditoria do selinux estiverem limpos, o problema SERÁ ALGUNS direitos de acesso relacionados ao daemon CGI, não aos arquivos listados na mensagem de erro. O daemon CGI deve ser capaz de localizar e gravar várias coisas.
O mpm_event_module agora é freqüentemente especificado no tempo de compilação do httpd na maioria dos pacotes, o que faz com que o httpd defina o padrão como mod_cgid ao invés de mod_cgi.
Qualquer uma das sugestões nas outras respostas pode funcionar ou não. Por exemplo, outro caso encontrado foi quando criamos um grupo de "sites" para que usuários específicos pudessem acessar o conteúdo do site sem afrouxar outras permissões. O diretório / var / run tinha "apache" como seu grupo, o que criou uma negação de permissões ao tentar criar o soquete.
confirme que você tem abaixo as configurações em 00-mpm.conf
/etc/httpd/conf.modules.d/00-mpm.conf
e comente mod_mpm_prefork.so comente o módulo mod_mpm_worker.so
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
#LoadModule mpm_worker_module modules/mod_mpm_worker.so
#LoadModule mpm_event_module modules/mod_mpm_event.so