Squid shm_open : accès refusé — vérifiez la propriété de la mémoire partagée

Could not read pid file et shm_open(...): Permission denied peuvent apparaître lors d'un même démarrage de Squid en échec. Ils désignent des ressources différentes. Corriger la propriété d'un répertoire de cache ne règle, à lui seul, aucun des deux.

Sous Linux, un objet de mémoire partagée POSIX est généralement représenté sous /dev/shm. Son propriétaire et son mode d'accès comptent. Un objet laissé par une autre identité d'exécution peut donc faire échouer un processus ultérieur, même lorsque squid.conf est lisible et que le port d'écoute est libre.

Reconstituez comment cette instance a démarré

Comparez le lancement normal du service avec tout lancement manuel utilisé pendant le diagnostic. Un processus démarré à la main et le service empaqueté peuvent utiliser des utilisateurs, des chemins ou des fichiers de configuration différents. Déterminez si une autre instance de Squid tourne encore avant de considérer un objet comme obsolète.

Lisez ensuite l'opération exacte qui échoue. Une erreur de PID concerne l'emplacement configuré du PID et son répertoire parent. Une erreur de journal concerne le fichier ou le répertoire de journal. Une erreur d'initialisation du cache concerne le stockage. Une erreur shm_open concerne l'objet de mémoire partagée nommé et peut aussi impliquer la politique de sécurité appliquée au processus.

Pour chaque ressource, comparez l'accès d'exécution requis avec son propriétaire et son mode actuels. Si les permissions ordinaires semblent suffisantes, examinez les preuves de refus correspondantes dans SELinux ou AppArmor. “Permission denied” seul n'indique pas quelle couche a refusé l'accès.

Réparez la propriété sans créer un second problème

Gardez le compte d'exécution cohérent avec la configuration du service de l'installation. Tout basculer vers nobody peut casser l'accès des programmes auxiliaires et introduire un nouveau décalage avec les fichiers gérés par le service.

Supprimer tous les objets qui ressemblent à Squid dans /dev/shm n'est pas non plus un bon premier réflexe. Un objet nommé peut appartenir à une instance active. Le nettoyage, lorsqu'il est nécessaire, doit viser une ressource abandonnée confirmée, le service concerné arrêté, puis un démarrage par le mécanisme normal du service.

Le résultat utile est un modèle de lancement et de propriété cohérent. Exécuter une seule commande en root jusqu'à ce que l'erreur disparaisse peut laisser le prochain redémarrage de routine avec exactement le même problème.