Finding Squid's Real File-Descriptor Limit
Read the running proxy's process limits before changing PAM settings or copying a fixed nofile value from a capacity recipe.
Inspect the running daemon before trusting the login shell's ulimit -n. For an installation using squid.service, start with:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceRead /proc/PID/limits using the actual process ID. In a multi-process deployment, check the relevant worker as well. A value saved in configuration is not proof that this process inherited it.
| Control | Scope |
|---|---|
Shell ulimit and PAM limits.conf | The shell's descendants or sessions that actually use the PAM setting |
systemd LimitNOFILE= | Processes started under that service's resource policy |
Squid max_filedescriptors, where supported | Application limit within the operating-system constraints |
A system service does not adopt PAM edits merely because an administrator changed the file. Use a service-specific drop-in when changing its systemd limit is appropriate. Squid documents that max_filedescriptors requires a restart to change; leaving it unset inherits the OS soft limit.
Size the limit for descriptors rather than users. Clients can hold several sockets, and onward connections, logs and helper pipes consume descriptors too. Raising the limit allows more consumption without immediately reserving a fixed amount of RAM per possible descriptor. Neither an old memory-per-socket estimate nor 65,535 is a universal capacity requirement or Linux ceiling.
After the service change, compare the new process's limits with the intended values. If failures occur well below them, investigate the resource actually being exhausted.