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 ആയി ഒരു കമാൻഡ് ഓടിക്കുന്നത് അടുത്ത സാധാരണ പുനരാരംഭത്തെ അതേ പ്രശ്നവുമായി വിടാം.