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 反复执行某条命令直到报错消失，可能让下一次例行重启仍然遇到完全相同的问题。