Squid shm_open: piekļuve liegta — pārbaudiet koplietotās atmiņas īpašnieku
Atdaliet Squid koplietotās atmiņas īpašnieka kļūmes no PID, žurnāla un kešatmiņas direktorija atļauju kļūdām.
Could not read pid file un shm_open(...): Permission denied var parādīties vienas neveiksmīgas Squid palaišanas laikā. Tie norāda uz dažādiem resursiem. Kešatmiņas direktorija īpašnieka labošana pati par sevi nelabo nevienu no tiem.
Linux sistēmā POSIX koplietotās atmiņas objekts parasti tiek attēlots zem /dev/shm. Tā īpašnieks un piekļuves režīms ir svarīgi. Tāpēc objekts, ko atstājusi cita izpildes identitāte, var izraisīt vēlākas procesa kļūmi pat tad, ja squid.conf ir lasāms un klausīšanās ports ir brīvs.
Rekonstruējiet, kā šī instance tika palaista
Salīdziniet parasto pakalpojuma palaišanu ar jebkuru manuālo palaišanu, kas izmantota problēmu novēršanā. Manuāli palaists process un iepakotais pakalpojums var izmantot dažādus lietotājus, ceļus vai konfigurācijas failus. Noskaidrojiet, vai vēl darbojas cita Squid instance, pirms objektu uzskatāt par novecojušu.
Pēc tam izlasiet precīzo neizdevušos darbību. PID kļūda attiecas uz konfigurēto PID atrašanās vietu un tās vecākdirektoriju. Žurnāla kļūda attiecas uz žurnāla failu vai direktoriju. Kešatmiņas inicializācijas kļūda attiecas uz krātuvi. shm_open kļūda attiecas uz nosaukto koplietotās atmiņas objektu un var ietvert arī procesam piemēroto drošības politiku.
Katram resursam salīdziniet nepieciešamo izpildes piekļuvi ar tā pašreizējo īpašnieku un režīmu. Ja parastās atļaujas šķiet pietiekamas, pārbaudiet attiecīgos SELinux vai AppArmor liegšanas pierādījumus. Tikai “Permission denied” nenorāda, kurš slānis liedza piekļuvi.
Labojiet īpašnieku, neradot otru problēmu
Uzturiet izpildes kontu saskaņā ar instalācijas pakalpojuma konfigurāciju. Visu pārslēgšana uz nobody var salauzt palīgprogrammu piekļuvi un ieviest jaunu neatbilstību ar pakalpojuma pārvaldītiem failiem.
Arī visu uz Squid līdzīgu objektu dzēšana /dev/shm nav labs pirmais solis. Nosauktais objekts var piederēt aktīvai instancei. Tīrīšana, ja nepieciešama, jāvērš uz apstiprinātu pamestu resursu, apturot skarto pakalpojumu, un pēc tam jāpalaiž ar parasto pakalpojuma mehānismu.
Noderīgais rezultāts ir konsekvents palaišanas un īpašnieka modelis. Vienas komandas izpilde kā root, līdz kļūda pazūd, var atstāt nākamo parasto restartu ar tieši tādu pašu problēmu.