Squid shm_open: permeso rifuzita — kontrolu posedon de la komuna memoro
Apartigu malsukcesojn de posedo de la komuna memoro de Squid disde permeseraroj pri PID, protokolo kaj kaŝmemora dosierujo.
Could not read pid file kaj shm_open(...): Permission denied povas aperi dum la sama malsukcesa lanĉo de Squid. Ili nomas malsamajn rimedojn. Ripari la posedon de kaŝmemora dosierujo mem ne riparas iun ajn el ili.
En Linukso, POSIX-objekto de komuna memoro estas kutime prezentata sub /dev/shm. Ĝia posedanto kaj alirmodo gravas. Objekto lasita de alia plenumidenteco povas do kaŭzi malsukceson de posta procezo, eĉ kiam squid.conf estas legebla kaj la aŭskultanta pordo estas libera.
Rekonstruu, kiel ĉi tiu aparato ekfunkciis
Komparu la normalan servolanĉon kun iu ajn mana lanĉo uzita dum la problemoserĉado. Mane startigita procezo kaj la paka servo povas uzi malsamajn uzantojn, vojojn aŭ agordodosierojn. Konstatu, ĉu alia Squid-aparato ankoraŭ funkcias, antaŭ ol konsideri objekton kaduka.
Poste legu la precizan malsukcesan operacion. PID-eraro koncernas la agorditan PID-lokon kaj ĝian gepatran dosierujon. Protokola eraro koncernas la protokolan dosieron aŭ dosierujon. Kaŝmemora inicialig-eraro koncernas la konservejon. shm_open-eraro koncernas la nomitan objekton de komuna memoro kaj povas ankaŭ koncerni la sekurecan politikon aplikatan al la procezo.
Por ĉiu rimedo, komparu la bezonatan plenum-aliron kun ĝia nuna posedanto kaj modo. Se ordinaraj permesoj ŝajnas sufiĉaj, ekzamenu la koncernajn rifuzajn pruvojn de SELinux aŭ AppArmor. Nur “Permission denied” ne montras, kiu tavolo rifuzis aliron.
Riparu posedon sen krei duan problemon
Konservu la plenumkonton kongrua kun la serva agordo de la instalaĵo. Ŝanĝi ĉion al nobody povas rompi aliron de helpiloj kaj enkonduki novan malkongruon kun servoadministrataj dosieroj.
Ankaŭ forigi ĉiun Squid-similan objekton en /dev/shm ne estas bona unua paŝo. Noma objekto povas aparteni al aktiva aparato. Purigado, kie necese, celi konfirmitan forlasitan rimedon kun la trafita servo haltigita, sekvata de ekfunkciigo per la normala servmekanismo.
La utila rezulto estas konsekvenca modelo de lanĉo kaj posedo. Ruli unu komandon kiel root ĝis la eraro malaperos povas lasi la sekvan rutinan restartigon kun ĝuste la sama problemo.