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 จนข้อผิดพลาดหายไปอาจทิ้งการรีสตาร์ตตามปกติครั้งถัดไปไว้กับปัญหาเดิมทุกประการ

บทความที่เกี่ยวข้อง