Squid shm_open: permesso negato — controllate la proprietà della memoria condivisa
Distinguete i guasti di proprietà della memoria condivisa di Squid dagli errori di permessi su PID, log e directory della cache.
Could not read pid file e shm_open(...): Permission denied possono comparire durante lo stesso avvio di Squid non riuscito. Indicano risorse diverse. Correggere la proprietà di una directory della cache non risolve, da solo, nessuno dei due.
Su Linux, un oggetto di memoria condivisa POSIX è di solito rappresentato sotto /dev/shm. Contano il proprietario e la modalità di accesso. Un oggetto lasciato da un'altra identità di esecuzione può quindi far fallire un processo successivo, anche quando squid.conf è leggibile e la porta in ascolto è libera.
Ricostruite come è partita questa istanza
Confrontate l'avvio normale del servizio con qualsiasi avvio manuale usato durante la diagnosi. Un processo avviato a mano e il servizio confezionato possono usare utenti, percorsi o file di configurazione diversi. Stabilite se un'altra istanza di Squid è ancora in esecuzione prima di considerare un oggetto obsoleto.
Leggete poi l'operazione esatta che fallisce. Un errore di PID riguarda la posizione configurata del PID e la sua directory padre. Un errore di log riguarda il file o la directory di log. Un errore di inizializzazione della cache riguarda l'archiviazione. Un errore shm_open riguarda l'oggetto di memoria condivisa con nome e può coinvolgere anche la politica di sicurezza applicata al processo.
Per ogni risorsa, confrontate l'accesso di esecuzione richiesto con il proprietario e la modalità attuali. Se i permessi ordinari sembrano sufficienti, esaminate le prove di rifiuto pertinenti in SELinux o AppArmor. Il solo “Permission denied” non indica quale livello ha negato l'accesso.
Riparate la proprietà senza creare un secondo problema
Mantenete l'account di esecuzione coerente con la configurazione del servizio dell'installazione. Spostare tutto su nobody può rompere l'accesso dei programmi ausiliari e introdurre un nuovo disallineamento con i file gestiti dal servizio.
Anche eliminare ogni oggetto che sembra di Squid in /dev/shm non è un buon primo passo. Un oggetto con nome può appartenere a un'istanza attiva. La pulizia, quando serve, deve puntare a una risorsa abbandonata confermata con il servizio interessato fermo, seguita dall'avvio tramite il normale meccanismo del servizio.
Il risultato utile è un modello di avvio e proprietà coerente. Eseguire un solo comando come root finché l'errore scompare può lasciare il successivo riavvio ordinario esattamente con lo stesso problema.