Squid shm_open: tinanggihan ang pahintulot — suriin ang pagmamay-ari ng shared memory
Ihiwalay ang mga pagkabigo sa pagmamay-ari ng shared memory ng Squid mula sa mga error sa pahintulot ng PID, log at cache directory.
Ang Could not read pid file at shm_open(...): Permission denied ay maaaring lumitaw sa parehong nabigong pag-start ng Squid. Magkaibang mapagkukunan ang tinutukoy nila. Ang pag-aayos ng pagmamay-ari ng isang cache directory ay hindi, sa sarili nito, nag-aayos ng alinman sa dalawa.
Sa Linux, ang isang POSIX shared memory object ay karaniwang kinakatawan sa ilalim ng /dev/shm. Mahalaga ang may-ari at ang access mode nito. Ang isang object na iniwan ng ibang runtime identity ay maaaring maging dahilan ng pagpalya ng susunod na proseso, kahit na ang squid.conf ay nababasa at ang listening port ay libre.
Muling buuin kung paano nagsimula ang instance na ito
Ihambing ang normal na pag-start ng serbisyo sa anumang manu-manong pag-start na ginamit habang nag-troubleshoot. Ang prosesong sinimulan nang manu-mano at ang naka-package na serbisyo ay maaaring gumamit ng ibang user, path o configuration file. Alamin kung may isa pang Squid instance na tumatakbo bago ituring na luma ang isang object.
Pagkatapos ay basahin ang eksaktong operasyong nabibigo. Ang PID error ay tungkol sa naka-configure na lokasyon ng PID at sa parent directory nito. Ang log error ay tungkol sa log file o directory. Ang error sa pagsisimula ng cache ay tungkol sa storage. Ang shm_open error ay tungkol sa pinangalanang shared memory object at maaaring kasama rin ang security policy na inilalapat sa proseso.
Para sa bawat mapagkukunan, ihambing ang kinakailangang runtime access sa kasalukuyang may-ari at mode nito. Kung sapat ang ordinaryong pahintulot, suriin ang kaugnay na ebidensiya ng pagtanggi sa SELinux o AppArmor. Ang “Permission denied” lamang ay hindi tumutukoy kung aling layer ang tumanggi sa access.
Ayusin ang pagmamay-ari nang hindi lumilikha ng pangalawang problema
Panatilihing pare-pareho ang runtime account sa configuration ng serbisyo ng installation. Ang paglilipat ng lahat sa nobody ay maaaring makasira sa access ng mga helper at magdala ng bagong mismatch sa mga file na pinamamahalaan ng serbisyo.
Hindi rin magandang unang hakbang ang pagtanggal ng bawat object na mukhang Squid sa /dev/shm. Ang isang pinangalanang object ay maaaring pag-aari ng aktibong instance. Ang paglilinis, kapag kailangan, ay dapat na nakatuon sa isang kumpirmadong inabandunang mapagkukunan habang naka-stop ang apektadong serbisyo, na sinusundan ng pag-start sa pamamagitan ng normal na mekanismo ng serbisyo.
Ang kapaki-pakinabang na resulta ay isang pare-parehong modelo ng pag-start at pagmamay-ari. Ang pagpapatakbo ng isang command bilang root hanggang mawala ang error ay maaaring mag-iwan sa susunod na regular na restart na may eksaktong parehong problema.