Squid shm_open: การอนุญาตถูกปฏิเสธ — ตรวจสอบความเป็นเจ้าของหน่วยความจำที่ใช้ร่วมกัน
แยกความล้มเหลวด้านความเป็นเจ้าของหน่วยความจำที่ใช้ร่วมกันของ Squid ออกจากข้อผิดพลาดด้านสิทธิ์ของ PID บันทึก และไดเรกทอรีแคช
Could not read pid file และ shm_open(...): Permission denied อาจปรากฏขึ้นระหว่างการเริ่ม Squid ที่ล้มเหลวครั้งเดียวกัน ทั้งสองชี้ไปที่ทรัพยากรที่ต่างกัน การแก้ไขความเป็นเจ้าของไดเรกทอรีแคชไม่ได้แก้ไขทั้งสองอย่างด้วยตัวเอง
บน Linux ออบเจ็กต์หน่วยความจำที่ใช้ร่วมกันแบบ POSIX มักแสดงอยู่ภายใต้ /dev/shm เจ้าของและโหมดการเข้าถึงมีความสำคัญ ดังนั้นออบเจ็กต์ที่ถูกทิ้งไว้โดยตัวตนการรันอื่นอาจทำให้โปรเซสในภายหลังล้มเหลวได้ แม้เมื่อ squid.conf อ่านได้และพอร์ตที่ฟังอยู่ว่าง
สร้างความเข้าใจใหม่ว่าอินสแตนซ์นี้เริ่มต้นอย่างไร
เปรียบเทียบการเริ่มบริการปกติกับการเริ่มด้วยมือใด ๆ ที่ใช้ระหว่างการแก้ปัญหา โปรเซสที่เริ่มด้วยมือและบริการที่แพ็กเกจอาจใช้ผู้ใช้ เส้นทาง หรือไฟล์กำหนดค่าที่ต่างกัน ตรวจสอบว่ามีอินสแตนซ์ Squid อื่นยังทำงานอยู่หรือไม่ก่อนถือว่าออบเจ็กต์ล้าสมัย
จากนั้นอ่านการดำเนินการที่ล้มเหลวอย่างแม่นยำ ข้อผิดพลาด PID เกี่ยวกับตำแหน่ง PID ที่กำหนดค่าไว้และไดเรกทอรีแม่ของมัน ข้อผิดพลาดบันทึกเกี่ยวกับไฟล์หรือไดเรกทอรีบันทึก ข้อผิดพลาดการเริ่มแคชเกี่ยวกับที่จัดเก็บ ข้อผิดพลาด shm_open เกี่ยวกับออบเจ็กต์หน่วยความจำที่ใช้ร่วมกันซึ่งมีชื่อ และอาจเกี่ยวข้องกับนโยบายความปลอดภัยที่ใช้กับโปรเซสด้วย
สำหรับแต่ละทรัพยากร ให้เปรียบเทียบการเข้าถึงขณะรันที่จำเป็นกับเจ้าของและโหมดปัจจุบัน หากสิทธิ์ทั่วไปดูเพียงพอ ให้ตรวจสอบหลักฐานการปฏิเสธที่เกี่ยวข้องใน SELinux หรือ AppArmor คำว่า “Permission denied” เพียงอย่างเดียวไม่ได้ระบุว่าชั้นใดปฏิเสธการเข้าถึง
แก้ไขความเป็นเจ้าของโดยไม่สร้างปัญหาใหม่
รักษาบัญชีการรันให้สอดคล้องกับการกำหนดค่าบริการของระบบที่ติดตั้ง การเปลี่ยนทุกอย่างไปเป็น nobody อาจทำให้การเข้าถึงของโปรแกรมช่วยเหลือเสียหายและสร้างความไม่ตรงกันใหม่กับไฟล์ที่บริการจัดการ
การลบทุกออบเจ็กต์ที่ดูเหมือน Squid ใน /dev/shm ก็ไม่ใช่ก้าวแรกที่ดี ออบเจ็กต์ที่มีชื่ออาจเป็นของอินสแตนซ์ที่ทำงานอยู่ การล้างข้อมูล เมื่อจำเป็น ควรกำหนดเป้าหมายไปที่ทรัพยากรที่ถูกทิ้งอย่างยืนยันแล้ว โดยหยุดบริการที่ได้รับผลกระทบก่อน แล้วจึงเริ่มผ่านกลไกบริการปกติ
ผลลัพธ์ที่เป็นประโยชน์คือรูปแบบการเริ่มและการเป็นเจ้าของที่สอดคล้องกัน การรันคำสั่งเดียวในฐานะ root จนข้อผิดพลาดหายไปอาจทิ้งการรีสตาร์ตตามปกติครั้งถัดไปไว้กับปัญหาเดิมทุกประการ