The PID File Vanishes. Check How systemd Starts Squid.
Match Squid foreground or daemon behavior to its systemd unit before treating a disappearing PID file as a permissions problem.
If Squid's PID file appears and immediately vanishes, compare the loaded unit's Type= with the actual executable and arguments. A Type=simple service expects its started process to remain the main process. A daemonizing command that forks and lets that process exit follows another contract; systemd can consider it finished and tear down the remaining service processes.
| Setting | Owner and purpose |
|---|---|
pid_filename | Squid writes its PID at this path on versions providing the directive |
PIDFile= | systemd reads a PID from this path where that service model needs it |
PIDFile= does not create the file or turn a daemonizing command into a foreground process. In a forking setup, service type, daemon behavior and path must agree. In a foreground setup, the manager must track the intended persistent process.
Squid distinguishes -N, avoiding daemon mode, from --foreground, retaining the parent until its children finish. Choose according to the build and service arrangement. A packaged unit may instead use readiness notification or other build-specific options; preserve that model when customizing it.
Now compare the journal with Squid's startup messages. A syntax error, inaccessible runtime directory or fatal initialization can really terminate the service and remove its PID file. The disappearance alone does not distinguish that exit from incorrect process tracking. Repair the cause supported by those messages rather than changing directory ownership repeatedly.