Squid shm_open 권한 거부: 공유 메모리 소유권 확인

Could not read pid file과 shm_open(...): Permission denied은 같은 실패한 Squid 시작 중에 함께 나타날 수 있습니다. 두 메시지는 서로 다른 리소스를 가리킵니다. 캐시 디렉터리의 소유권을 고치는 것만으로는 둘 중 어느 것도 해결되지 않습니다.

Linux에서 POSIX 공유 메모리 객체는 보통 /dev/shm 아래에 표현됩니다. 그 소유자와 접근 모드가 중요합니다. 따라서 다른 런타임 ID가 남긴 객체는 squid.conf이 읽을 수 있고 수신 포트가 비어 있어도 이후 프로세스를 실패시킬 수 있습니다.

이 인스턴스가 어떻게 시작되었는지 재구성합니다

정상 서비스 시작과 문제 해결 중 사용한 수동 시작을 비교합니다. 수동으로 시작한 프로세스와 패키지된 서비스는 사용자, 경로 또는 설정 파일이 다를 수 있습니다. 객체를 오래된 것으로 판단하기 전에 다른 Squid 인스턴스가 아직 실행 중인지 확인합니다.

그다음 실패하는 정확한 작업을 읽습니다. PID 오류는 설정된 PID 위치와 상위 디렉터리에 관한 것입니다. 로그 오류는 로그 파일이나 디렉터리에 관한 것입니다. 캐시 초기화 오류는 스토리지에 관한 것입니다. shm_open 오류는 이름이 지정된 공유 메모리 객체에 관한 것이며 프로세스에 적용되는 보안 정책도 관련될 수 있습니다.

각 리소스마다 필요한 런타임 접근 권한을 현재 소유자와 모드와 비교합니다. 일반 권한이 충분해 보이면 관련 SELinux 또는 AppArmor 거부 증거를 확인합니다. “Permission denied”만으로는 어느 계층이 접근을 거부했는지 알 수 없습니다.

두 번째 문제 없이 소유권을 고칩니다

런타임 계정을 설치의 서비스 구성과 일치시킵니다. 모든 것을 nobody로 바꾸면 보조 프로그램 접근이 깨지고 서비스가 관리하는 파일과 새 불일치가 생길 수 있습니다.

/dev/shm에서 Squid처럼 보이는 객체를 모두 삭제하는 것도 좋은 첫 단계가 아닙니다. 이름이 지정된 객체는 활성 인스턴스의 것일 수 있습니다. 정리가 필요하면 영향을 받은 서비스를 중지한 상태에서 확인된 방치 리소스만 대상으로 하고, 이후 정상 서비스 메커니즘으로 시작합니다.

유용한 결과는 일관된 시작 및 소유권 모델입니다. 오류가 사라질 때까지 root로 명령 하나를 계속 실행하면 다음 정기 재시작에 똑같은 문제가 남을 수 있습니다.