Squid shm_open: приступ одбијен — проверите власништво дељене меморије
Одвојте кварове власништва дељене меморије Squid-а од грешака дозвола за PID, дневник и директоријум кеша.
Could not read pid file и shm_open(...): Permission denied могу се појавити током истог неуспелог покретања Squid-а. Они именују различите ресурсе. Исправљање власништва директоријума кеша само по себи не исправља ниједан од њих.
На Linux-у је POSIX објекат дељене меморије обично представљен под /dev/shm. Његов власник и режим приступа су важни. Зато објекат који је оставио други идентитет извршавања може изазвати неуспех каснијег процеса, чак и када је squid.conf читљив и порт за слушање слободан.
Реконструишите како је ова инстанца покренута
Упоредите уобичајено покретање услуге са било којим ручним покретањем коришћеним током решавања проблема. Ручно покренут процес и пакована услуга могу користити различите кориснике, путање или конфигурационе датотеке. Утврдите да ли је друга инстанца Squid-а још активна пре него што објекат сматрате застарелим.
Затим прочитајте тачну операцију која не успева. Грешка PID-а односи се на конфигурисану локацију PID-а и њен надређени директоријум. Грешка дневника односи се на датотеку или директоријум дневника. Грешка иницијализације кеша односи се на складиште. Грешка shm_open односи се на именовани објекат дељене меморије и може укључивати и безбедносну политику примењену на процес.
За сваки ресурс упоредите потребан приступ при извршавању са његовим тренутним власником и режимом. Ако се уобичајене дозволе чине довољним, прегледајте одговарајуће доказе одбијања у SELinux-у или AppArmor-у. Само “Permission denied” не показује који је слој одбио приступ.
Исправите власништво без стварања другог проблема
Држите рачун извршавања усклађеним са конфигурацијом услуге инсталације. Пребацивање свега на nobody може покварити приступ помоћних алата и унети ново неслагање са датотекама којима управља услуга.
Ни брисање сваког објекта налик Squid-у у /dev/shm није добар први потез. Именовани објекат може припадати активној инстанци. Чишћење, када је потребно, треба да циља потврђени напуштени ресурс уз заустављену погођену услугу, а затим покретање кроз уобичајени механизам услуге.
Користан резултат је доследан модел покретања и власништва. Покретање једне команде као root док грешка не нестане може оставити следеће рутинско поновно покретање са потпуно истим проблемом.