Squid shm_open: odmowa dostępu — sprawdź własność pamięci współdzielonej
Oddziel błędy własności pamięci współdzielonej Squida od błędów uprawnień do PID, dziennika i katalogu pamięci podręcznej.
Could not read pid file i shm_open(...): Permission denied mogą pojawić się podczas tego samego nieudanego uruchomienia Squida. Wskazują na różne zasoby. Naprawa własności katalogu pamięci podręcznej sama w sobie nie naprawia żadnego z nich.
W systemie Linux obiekt pamięci współdzielonej POSIX jest zwykle reprezentowany pod /dev/shm. Jego właściciel i tryb dostępu mają znaczenie. Obiekt pozostawiony przez inną tożsamość wykonawczą może więc spowodować awarię późniejszego procesu, nawet gdy squid.conf jest czytelny, a port nasłuchujący jest wolny.
Odtwórz, jak uruchomiono tę instancję
Porównaj normalne uruchomienie usługi z dowolnym uruchomieniem ręcznym użytym podczas diagnozy. Proces uruchomiony ręcznie i usługa z pakietu mogą używać innych użytkowników, ścieżek lub plików konfiguracyjnych. Ustal, czy inna instancja Squida nadal działa, zanim uznasz obiekt za nieaktualny.
Następnie odczytaj dokładną zawodną operację. Błąd PID dotyczy skonfigurowanej lokalizacji PID i jej katalogu nadrzędnego. Błąd dziennika dotyczy pliku lub katalogu dziennika. Błąd inicjalizacji pamięci podręcznej dotyczy magazynu. Błąd shm_open dotyczy nazwanego obiektu pamięci współdzielonej i może obejmować także politykę bezpieczeństwa stosowaną do procesu.
Dla każdego zasobu porównaj wymagany dostęp wykonawczy z jego bieżącym właścicielem i trybem. Jeśli zwykłe uprawnienia wydają się wystarczające, przejrzyj odpowiednie dowody odmowy w SELinux lub AppArmor. Samo “Permission denied” nie wskazuje, która warstwa odmówiła dostępu.
Napraw własność, nie tworząc drugiego problemu
Utrzymuj konto wykonawcze zgodne z konfiguracją usługi instalacji. Przełączenie wszystkiego na nobody może zepsuć dostęp programów pomocniczych i wprowadzić nową niezgodność z plikami zarządzanymi przez usługę.
Usunięcie każdego obiektu przypominającego Squida w /dev/shm też nie jest dobrym pierwszym krokiem. Nazwany obiekt może należeć do aktywnej instancji. Czyszczenie, gdy jest konieczne, powinno dotyczyć potwierdzonego porzuconego zasobu przy zatrzymanej usłudze, a następnie uruchomienia zwykłym mechanizmem usługi.
Użytecznym wynikiem jest spójny model uruchamiania i własności. Uruchamianie jednego polecenia jako root, aż błąd zniknie, może pozostawić następny rutynowy restart z dokładnie tym samym problemem.