Squid shm_open: permiso denegado — compruebe la propiedad de la memoria compartida
Separe los fallos de propiedad de la memoria compartida de Squid de los errores de permisos de PID, registro y directorio de caché.
Could not read pid file y shm_open(...): Permission denied pueden aparecer durante un mismo arranque fallido de Squid. Nombran recursos distintos. Corregir la propiedad de un directorio de caché no corrige, por sí solo, ninguno de los dos.
En Linux, un objeto de memoria compartida POSIX suele representarse bajo /dev/shm. Su propietario y su modo de acceso importan. Por eso, un objeto dejado por otra identidad de ejecución puede hacer fallar un proceso posterior incluso cuando squid.conf es legible y el puerto de escucha está libre.
Reconstruya cómo se inició esta instancia
Compare el arranque normal del servicio con cualquier arranque manual usado durante el diagnóstico. Un proceso iniciado a mano y el servicio empaquetado pueden usar usuarios, rutas o archivos de configuración distintos. Determine si otra instancia de Squid sigue en ejecución antes de tratar un objeto como obsoleto.
Después lea la operación exacta que falla. Un error de PID afecta a la ubicación configurada del PID y a su directorio padre. Un error de registro afecta al archivo o al directorio de registro. Un error de inicialización de la caché afecta al almacenamiento. Un error de shm_open afecta al objeto de memoria compartida con nombre y puede implicar también la política de seguridad aplicada al proceso.
Para cada recurso, compare el acceso de ejecución requerido con su propietario y modo actuales. Si los permisos ordinarios parecen suficientes, revise las pruebas de denegación correspondientes de SELinux o AppArmor. “Permission denied” por sí solo no identifica qué capa denegó el acceso.
Repare la propiedad sin crear un segundo problema
Mantenga la cuenta de ejecución coherente con la configuración del servicio de la instalación. Cambiar todo a nobody puede romper el acceso de los programas auxiliares e introducir un nuevo desajuste con los archivos gestionados por el servicio.
Borrar todos los objetos que parezcan de Squid en /dev/shm tampoco es un buen primer paso. Un objeto con nombre puede pertenecer a una instancia activa. La limpieza, cuando haga falta, debe apuntar a un recurso abandonado confirmado con el servicio afectado detenido y, después, arrancar mediante el mecanismo normal del servicio.
El resultado útil es un modelo coherente de arranque y propiedad. Ejecutar un solo comando como root hasta que el error desaparezca puede dejar el siguiente reinicio rutinario con exactamente el mismo problema.