Squid shm_open icazəsi rədd edildi: paylaşılan yaddaşın sahibliyini yoxlayın
Squid-in paylaşılan yaddaş sahibliyi xətalarını PID, jurnal və keş qovluğu icazə xətalarından ayırın.
Could not read pid file və shm_open(...): Permission denied eyni uğursuz Squid başlatması zamanı görünə bilər. Onlar müxtəlif resursları adlandırır. Keş qovluğunun sahibliyini düzəltmək tək başına bunlardan heç birini həll etmir.
Linux-da POSIX paylaşılan yaddaş obyekti adətən /dev/shm altında təmsil olunur. Onun sahibi və giriş rejimi vacibdir. Başqa işləmə kimliyinin qoyub getdiyi obyekt buna görə sonrakı prosesi uğursuz edə bilər, hətta squid.conf oxuna bilən və dinləyən port sərbəst olsa belə.
Bu instansın necə başladığını bərpa edin
Normal xidmət başlatmasını nasazlıq axtarışı zamanı istifadə olunan əl ilə başlatma ilə müqayisə edin. Əl ilə başladılan proses və paketlənmiş xidmət fərqli istifadəçilər, yollar və ya konfiqurasiya faylları istifadə edə bilər. Hər hansı obyekti köhnəlmiş hesab etməzdən əvvəl başqa Squid instansının hələ də işləyib-işləmədiyini müəyyən edin.
Sonra uğursuz olan dəqiq əməliyyatı oxuyun. PID xətası konfiqurasiya edilmiş PID yerinə və onun ana qovluğuna aiddir. Jurnal xətası jurnal faylına və ya qovluğuna aiddir. Keşin işə salınması xətası yaddaş saxlamasına aiddir. shm_open xətası adlandırılmış paylaşılan yaddaş obyektinə aiddir və prosesə tətbiq olunan təhlükəsizlik siyasətini də əhatə edə bilər.
Hər resurs üçün tələb olunan işləmə girişini onun hazırkı sahibi və rejimi ilə müqayisə edin. Adi icazələr kifayət görünürsə, müvafiq SELinux və ya AppArmor rədd sübutunu yoxlayın. Tək “Permission denied” hansı qatın girişi rədd etdiyini göstərmir.
İkinci problem yaratmadan sahibliyi bərpa edin
İşləmə hesabını quraşdırmanın xidmət konfiqurasiyası ilə uyğun saxlayın. Hər şeyi nobody-ə keçirmək köməkçi girişini poza və xidmətin idarə etdiyi fayllarla yeni uyğunsuzluq yarada bilər.
/dev/shm daxilində Squid-ə bənzəyən hər obyekti silmək də yaxşı ilk addım deyil. Adlandırılmış obyekt aktiv instansa aid ola bilər. Təmizləmə, lazım olduqda, təsirlənmiş xidmət dayandırılmış vəziyyətdə təsdiqlənmiş tərk edilmiş resursa yönəlməli, sonra normal xidmət mexanizmi ilə başlatma aparılmalıdır.
Faydalı nəticə ardıcıl başlatma və sahiblik modelidir. Xəta yox olana qədər root kimi bir əmr işlətmək növbəti adi yenidən başlatmanı tam eyni problemlə qoyub gedə bilər.