I got the same result as Mohsen. The only thing that worked was adding "ulimit -n mynumber" to the init script. It was weird for me, because the script is run by root, not the squid user, and i thought ulimit -n applied only to the current logged in user. But I think it applies to any session that will start later. But at boot time, seems like PAM has no effect. I'm using RHEL with SELinux. Maybe it is a SELinux behavior... On Sun, Sep 15, 2013 at 8:14 AM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote: > What?? > what OS are you using? > > Eliezer > > On 09/15/2013 09:07 AM, Mohsen Dehghani wrote: >> All workarounds failed except adding "ulimit -n 65000" to squid init file >> >> Adding "session required pam_limits.so" to "/etc/pam.d/common-session" also >> failed for me. >> The box never read '/etc/security/limits.conf' at boot time >> >> OK so now there is another thing That I have tested: >> /etc/pam.d/common-session >> dosn't have the limit module as a default so the admin will set it as he >> wants and to prevent a problem.. >> >> adding this line: >> session required pam_limits.so >> >> to the common-session file forces the ulimits on a PAM session startup and >> end.. >> this forces the bash(which is a pam) session to use the limits that are set >> by the admin in the limits.conf... >> It's not such a good idea to allow a users such a thing but this is the >> admin choice. >> >> Eliezer >> >> >
