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_at_ngtech.co.il> 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
>>>
>>>
>>
Received on Sun Sep 15 2013 - 14:28:57 MDT
This archive was generated by hypermail 2.2.0 : Sun Sep 15 2013 - 12:00:04 MDT