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-ით გაშვებამ, სანამ შეცდომა გაქრება, შემდეგი ჩვეულებრივი გადატვირთვა ზუსტად იმავე პრობლემით შეიძლება დატოვოს.

დაკავშირებული სტატიები