Squid shm_open: permissão negada — verifique a propriedade da memória partilhada
Separe as falhas de propriedade da memória partilhada do Squid dos erros de permissão de PID, registo e diretório de cache.
Could not read pid file e shm_open(...): Permission denied podem surgir durante o mesmo arranque falhado do Squid. Nomeiam recursos diferentes. Corrigir a propriedade de um diretório de cache não corrige, por si só, nenhum deles.
No Linux, um objeto de memória partilhada POSIX é normalmente representado em /dev/shm. O proprietário e o modo de acesso importam. Um objeto deixado por outra identidade de execução pode, por isso, fazer falhar um processo posterior, mesmo quando squid.conf é legível e a porta de escuta está livre.
Reconstrua como esta instância arrancou
Compare o arranque normal do serviço com qualquer arranque manual usado durante o diagnóstico. Um processo iniciado manualmente e o serviço empacotado podem usar utilizadores, caminhos ou ficheiros de configuração diferentes. Determine se outra instância do Squid ainda está em execução antes de tratar um objeto como obsoleto.
Depois leia a operação exata que falha. Um erro de PID diz respeito à localização configurada do PID e ao seu diretório pai. Um erro de registo diz respeito ao ficheiro ou diretório de registo. Um erro de inicialização da cache diz respeito ao armazenamento. Um erro de shm_open diz respeito ao objeto de memória partilhada com nome e pode também envolver a política de segurança aplicada ao processo.
Para cada recurso, compare o acesso de execução necessário com o proprietário e o modo atuais. Se as permissões normais parecerem suficientes, examine as provas de recusa relevantes no SELinux ou no AppArmor. Apenas “Permission denied” não identifica que camada recusou o acesso.
Repare a propriedade sem criar um segundo problema
Mantenha a conta de execução coerente com a configuração do serviço da instalação. Passar tudo para nobody pode quebrar o acesso dos programas auxiliares e introduzir um novo desalinhamento com os ficheiros geridos pelo serviço.
Apagar todos os objetos que parecem do Squid em /dev/shm também não é um bom primeiro passo. Um objeto com nome pode pertencer a uma instância ativa. A limpeza, quando necessária, deve visar um recurso abandonado confirmado com o serviço afetado parado e, depois, um arranque pelo mecanismo normal do serviço.
O resultado útil é um modelo coerente de arranque e propriedade. Executar um único comando como root até o erro desaparecer pode deixar o próximo reinício de rotina exatamente com o mesmo problema.