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-ке ауыстыру көмекші бағдарламалардың қатынауын бұзып, қызмет басқаратын файлдармен жаңа сәйкессіздік әкелуі мүмкін.
/dev/shm ішіндегі Squid-қа ұқсайтын барлық нысанды жою да жақсы бірінші қадам емес. Аталған нысан белсенді данаға тиесілі болуы мүмкін. Тазарту, қажет болса, әсер еткен қызмет тоқтатылған күйде расталған тасталған ресурсқа бағытталып, кейін қызметтің қалыпты механизмі арқылы іске қосылуы керек.
Пайдалы нәтиже — үйлесімді іске қосу және иелік моделі. Қате жоғалғанша root ретінде бір пәрменді орындау келесі күнделікті қайта іске қосуды дәл сол мәселемен қалдыруы мүмкін.