Squid shm_open: izin reddedildi — paylaşılan belleğin sahipliğini denetleyin
Squid'in paylaşılan bellek sahipliği arızalarını PID, günlük ve önbellek dizini izin hatalarından ayırın.
Could not read pid file ve shm_open(...): Permission denied aynı başarısız Squid başlatması sırasında görünebilir. Farklı kaynakları adlandırırlar. Bir önbellek dizininin sahipliğini düzeltmek tek başına ikisini de çözmez.
Linux'ta POSIX paylaşılan bellek nesnesi genellikle /dev/shm altında temsil edilir. Sahibi ve erişim kipi önemlidir. Bu nedenle başka bir çalışma kimliğinin bıraktığı bir nesne, squid.conf okunabilir ve dinleme bağlantı noktası boş olsa bile sonraki sürecin başarısız olmasına yol açabilir.
Bu örneğin nasıl başlatıldığını yeniden kurun
Olağan hizmet başlatmasını, sorun giderme sırasında kullanılan herhangi bir elle başlatmayla karşılaştırın. Elle başlatılan süreç ile paketlenmiş hizmet farklı kullanıcılar, yollar veya yapılandırma dosyaları kullanabilir. Bir nesneyi eski saymadan önce başka bir Squid örneğinin hâlâ çalışıp çalışmadığını belirleyin.
Ardından başarısız olan tam işlemi okuyun. PID hatası, yapılandırılmış PID konumunu ve üst dizinini ilgilendirir. Günlük hatası, günlük dosyasını veya dizinini ilgilendirir. Önbellek başlatma hatası depolamayı ilgilendirir. shm_open hatası, adlandırılmış paylaşılan bellek nesnesini ilgilendirir ve sürece uygulanan güvenlik ilkesini de kapsayabilir.
Her kaynak için gereken çalışma erişimini geçerli sahibi ve kipiyle karşılaştırın. Olağan izinler yeterli görünüyorsa ilgili SELinux veya AppArmor ret kanıtlarını inceleyin. Tek başına “Permission denied” erişimi hangi katmanın reddettiğini göstermez.
İkinci bir sorun yaratmadan sahipliği onarın
Çalışma hesabını kurulumun hizmet yapılandırmasıyla tutarlı tutun. Her şeyi nobody hesabına geçirmek yardımcı programların erişimini bozabilir ve hizmetin yönettiği dosyalarla yeni bir uyumsuzluk getirebilir.
/dev/shm içindeki Squid'e benzeyen her nesneyi silmek de iyi bir ilk adım değildir. Adlandırılmış bir nesne etkin bir örneğe ait olabilir. Temizlik gerektiğinde, etkilenen hizmet durdurulmuşken doğrulanmış terk edilmiş bir kaynağı hedeflemeli, ardından normal hizmet mekanizmasıyla başlatılmalıdır.
Yararlı sonuç tutarlı bir başlatma ve sahiplik modelidir. Hata kaybolana kadar root olarak tek bir komut çalıştırmak, sonraki olağan yeniden başlatmayı tam olarak aynı sorunla bırakabilir.