Squid shm_open: prieiga uždrausta — patikrinkite bendrosios atminties savininką
Atskirkite Squid bendrosios atminties savininko gedimus nuo PID, žurnalo ir talpyklos katalogo leidimų klaidų.
Could not read pid file ir shm_open(...): Permission denied gali pasirodyti per tą patį nepavykusį Squid paleidimą. Jie nurodo skirtingus išteklius. Talpyklos katalogo savininko pataisymas pats savaime neištaiso nė vieno iš jų.
Linux sistemoje POSIX bendrosios atminties objektas paprastai pateikiamas po /dev/shm. Jo savininkas ir prieigos režimas yra svarbūs. Todėl kitos vykdymo tapatybės paliktas objektas gali sukelti vėlesnio proceso gedimą, net kai squid.conf yra skaitomas ir klausymosi prievadas laisvas.
Atkurkite, kaip ši kopija buvo paleista
Palyginkite įprastą paslaugos paleidimą su bet kokiu rankiniu paleidimu, naudotu sprendžiant problemą. Rankiniu būdu paleistas procesas ir supakuota paslauga gali naudoti skirtingus vartotojus, kelius ar konfigūracijos failus. Nustatykite, ar dar veikia kita Squid kopija, prieš laikydami objektą pasenusiu.
Tada perskaitykite tikslią nepavykstančią operaciją. PID klaida susijusi su sukonfigūruota PID vieta ir jos pagrindiniu katalogu. Žurnalo klaida susijusi su žurnalo failu ar katalogu. Talpyklos inicijavimo klaida susijusi su saugykla. shm_open klaida susijusi su pavadintu bendrosios atminties objektu ir gali apimti procesui taikomą saugumo politiką.
Kiekvienam ištekliui palyginkite reikalingą vykdymo prieigą su dabartiniu savininku ir režimu. Jei įprasti leidimai atrodo pakankami, peržiūrėkite atitinkamus SELinux arba AppArmor atmetimo įrodymus. Vien „Permission denied“ nenurodo, kuris sluoksnis atmetė prieigą.
Ištaisykite savininką nesukurdami antros problemos
Laikykite vykdymo paskyrą suderintą su diegimo paslaugos konfigūracija. Viską perjungti į nobody gali sugadinti pagalbinių programų prieigą ir įvesti naują neatitikimą su paslaugos valdomais failais.
Taip pat neištrinti visų į Squid panašių objektų /dev/shm kataloge nėra geras pirmas žingsnis. Pavadintas objektas gali priklausyti aktyviai kopijai. Valymas, kai jo reikia, turėtų būti nukreiptas į patvirtintą apleistą išteklių, sustabdžius paveiktą paslaugą, o po to paleisti įprastu paslaugos mechanizmu.
Naudingas rezultatas yra nuoseklus paleidimo ir savininko modelis. Vienos komandos vykdymas root teisėmis, kol klaida išnyks, gali palikti kitą įprastą paleidimą su ta pačia problema.