Squid shm_open: izin ditolak — periksa kepemilikan memori bersama

Could not read pid file dan shm_open(...): Permission denied dapat muncul pada kegagalan start Squid yang sama. Keduanya menunjuk sumber daya yang berbeda. Memperbaiki kepemilikan direktori cache tidak dengan sendirinya memperbaiki salah satunya.

Di Linux, objek memori bersama POSIX biasanya direpresentasikan di bawah /dev/shm. Pemilik dan mode aksesnya penting. Objek yang ditinggalkan oleh identitas runtime lain karena itu dapat membuat proses berikutnya gagal, bahkan ketika squid.conf dapat dibaca dan port pendengar bebas.

Rekonstruksi bagaimana instans ini dimulai

Bandingkan peluncuran layanan normal dengan peluncuran manual apa pun yang dipakai saat pemecahan masalah. Proses yang dijalankan manual dan layanan terpaket dapat memakai pengguna, jalur, atau berkas konfigurasi berbeda. Pastikan apakah instans Squid lain masih berjalan sebelum menganggap objek sebagai usang.

Lalu baca operasi tepat yang gagal. Kesalahan PID menyangkut lokasi PID yang dikonfigurasi dan direktori induknya. Kesalahan log menyangkut berkas atau direktori log. Kesalahan inisialisasi cache menyangkut penyimpanan. Kesalahan shm_open menyangkut objek memori bersama bernama dan dapat juga melibatkan kebijakan keamanan yang diterapkan pada proses.

Untuk setiap sumber daya, bandingkan akses runtime yang diperlukan dengan pemilik dan mode saat ini. Jika izin biasa tampak memadai, periksa bukti penolakan SELinux atau AppArmor yang relevan. “Permission denied” saja tidak menunjukkan lapisan mana yang menolak akses.

Perbaiki kepemilikan tanpa menciptakan masalah kedua

Jaga akun runtime tetap konsisten dengan konfigurasi layanan instalasi. Mengalihkan semuanya ke nobody dapat merusak akses pembantu dan memunculkan ketidakcocokan baru dengan berkas yang dikelola layanan.

Menghapus setiap objek yang tampak seperti Squid di /dev/shm juga bukan langkah pertama yang baik. Objek bernama bisa milik instans yang aktif. Pembersihan, bila diperlukan, harus menyasar sumber daya terbengkalai yang terkonfirmasi dengan layanan terdampak dihentikan, lalu start melalui mekanisme layanan normal.

Hasil yang berguna adalah model peluncuran dan kepemilikan yang konsisten. Menjalankan satu perintah sebagai root sampai kesalahan hilang dapat meninggalkan restart rutin berikutnya dengan masalah yang persis sama.