Squid shm_open: permiso denegado — comprobe a propiedade da memoria compartida
Separe os fallos de propiedade da memoria compartida de Squid dos erros de permisos de PID, rexistro e directorio de caché.
Could not read pid file e shm_open(...): Permission denied poden aparecer durante un mesmo arranque fallido de Squid. Nomean recursos distintos. Corrixir a propiedade dun directorio de caché non corrixe, por si só, ningún dos dous.
En Linux, un obxecto de memoria compartida POSIX adoita representarse baixo /dev/shm. O seu propietario e o seu modo de acceso importan. Por iso, un obxecto deixado por outra identidade de execución pode facer fallar un proceso posterior mesmo cando squid.conf é lexible e o porto de escoita está libre.
Reconstruída como se iniciou esta instancia
Compare o arranque normal do servizo con calquera arranque manual usado durante o diagnóstico. Un proceso iniciado a man e o servizo empaquetado poden usar usuarios, rutas ou ficheiros de configuración distintos. Determine se outra instancia de Squid segue en execución antes de tratar un obxecto como obsoleto.
Despois lea a operación exacta que falla. Un erro de PID afecta á localización configurada do PID e ao seu directorio pai. Un erro de rexistro afecta ao ficheiro ou ao directorio de rexistro. Un erro de inicialización da caché afecta ao almacenamento. Un erro de shm_open afecta ao obxecto de memoria compartida con nome e pode implicar tamén a política de seguranza aplicada ao proceso.
Para cada recurso, compare o acceso de execución requirido co seu propietario e modo actuais. Se os permisos ordinarios parecen suficientes, revise as probas de denegación correspondentes de SELinux ou AppArmor. “Permission denied” por si só non identifica que capa denegou o acceso.
Repare a propiedade sen crear un segundo problema
Manteña a conta de execución coherente coa configuración do servizo da instalación. Cambiar todo a nobody pode romper o acceso dos programas auxiliares e introducir un novo desaxuste cos ficheiros xestionados polo servizo.
Borrar todos os obxectos que parezan de Squid en /dev/shm tampouco é un bo primeiro paso. Un obxecto con nome pode pertencer a unha instancia activa. A limpeza, cando faga falta, debe apuntar a un recurso abandonado confirmado co servizo afectado detido e, despois, arrancar mediante o mecanismo normal do servizo.
O resultado útil é un modelo coherente de arranque e propiedade. Executar un só comando como root ata que o erro desapareza pode deixar o seguinte reinicio rutineiro con exactamente o mesmo problema.