Squid shm_open: अनुमति अस्वीकृत — साझा मेमोरी का स्वामित्व जाँचें

एक ही विफल Squid स्टार्टअप के दौरान Could not read pid file और shm_open(...): Permission denied दोनों दिख सकते हैं। वे अलग-अलग संसाधनों के नाम लेते हैं। कैश निर्देशिका का स्वामित्व ठीक करना अपने आप इनमें से किसी को भी नहीं ठीक करता।

Linux पर POSIX साझा मेमोरी ऑब्जेक्ट सामान्यतः /dev/shm के अंतर्गत दर्शाया जाता है। उसका स्वामी और पहुँच मोड मायने रखते हैं। इसलिए किसी दूसरी रनटाइम पहचान द्वारा छोड़ा गया ऑब्जेक्ट बाद की प्रक्रिया को विफल कर सकता है, तब भी जब squid.conf पढ़ने योग्य हो और सुनने वाला पोर्ट मुक्त हो।

यह इंस्टेंस कैसे शुरू हुआ, यह फिर से बनाएँ

सेवा के सामान्य प्रारंभ की तुलना समस्या-निवारण के दौरान किए गए किसी भी मैनुअल प्रारंभ से करें। मैनुअल रूप से शुरू की गई प्रक्रिया और पैकेज की गई सेवा अलग-अलग उपयोगकर्ता, पथ या कॉन्फ़िगरेशन फ़ाइलें उपयोग कर सकती हैं। किसी ऑब्जेक्ट को बासी मानने से पहले तय करें कि क्या कोई दूसरा Squid इंस्टेंस अभी भी चल रहा है।

फिर वह सटीक ऑपरेशन पढ़ें जो विफल हो रहा है। PID त्रुटि कॉन्फ़िगर किए गए PID स्थान और उसकी मूल निर्देशिका से संबंधित है। लॉग त्रुटि लॉग फ़ाइल या निर्देशिका से संबंधित है। कैश आरंभीकरण की त्रुटि भंडारण से संबंधित है। shm_open त्रुटि नामित साझा मेमोरी ऑब्जेक्ट से संबंधित है और प्रक्रिया पर लागू सुरक्षा नीति को भी शामिल कर सकती है।

प्रत्येक संसाधन के लिए आवश्यक रनटाइम पहुँच की तुलना उसके वर्तमान स्वामी और मोड से करें। यदि सामान्य अनुमतियाँ पर्याप्त लगें, तो संबंधित SELinux या AppArmor अस्वीकृति प्रमाण देखें। केवल “Permission denied” यह नहीं बताता कि किस परत ने पहुँच अस्वीकार की।

दूसरी समस्या बनाए बिना स्वामित्व ठीक करें

रनटाइम खाते को इंस्टॉलेशन की सेवा कॉन्फ़िगरेशन के अनुरूप रखें। सब कुछ nobody पर बदलने से सहायक पहुँच टूट सकती है और सेवा-प्रबंधित फ़ाइलों के साथ नई असंगति आ सकती है।

/dev/shm में Squid जैसा दिखने वाला हर ऑब्जेक्ट मिटा देना भी अच्छा पहला कदम नहीं है। नामित ऑब्जेक्ट किसी सक्रिय इंस्टेंस का हो सकता है। सफ़ाई, जहाँ आवश्यक हो, प्रभावित सेवा बंद होने पर पुष्टि किए गए परित्यक्त संसाधन को लक्षित करनी चाहिए, और उसके बाद सामान्य सेवा तंत्र के माध्यम से प्रारंभ करना चाहिए।

उपयोगी परिणाम एक सुसंगत प्रारंभ और स्वामित्व मॉडल है। त्रुटि गायब होने तक root के रूप में एक आदेश चलाना अगले नियमित पुनःआरंभ को ठीक उसी समस्या के साथ छोड़ सकता है।