On 09/15/2013 03:51 PM, Carlos Defoe wrote: > 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... Or this is how it was designed.. Eliezer > > > 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 >>> >>> >>
