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-ով գործարկելը, մինչև սխալը անհետանա, կարող է հաջորդ սովորական վերագործարկումը թողնել ճիշտ նույն խնդրով։