On 09/11/2013 07:19 AM, Mohsen Dehghani wrote:
>Thanks everybody
>
>[The problem resolved]
>After adding following lines to /etc/security/limits.conf
>root soft nofile 60000
>root hard nofile 60000
>
>but I am eager to know the rationale behind it, cuz squid runs as user "proxy" not "root"
On 09/16/2013 01:55 AM, Eliezer Croitoru wrote:
> Well for me it works when I start a shell using "su - user".
> But there is a need to know and map the linux boot process and them
> findout why bash is limited to 1024 FD instead of 4k or 4m.
> The basic issue is a security issue.. which I support enforcing as it is
> now.
> What squid can do as a process to force FD limit?
> squid as a limited process can only reach the LIMIT as at is now.
> since squid 3.2 does a "forking" style under-the-ground it is indeed the
> best practice to limit the init.d script access and execution..
> then upper the ULIMIT in the init.d script to make sure that the limit
> makes sense..
> if there is a start-stop-daemon feature then this is why it was invented
> anyway.
> So we can choose to either work with an execution proxy the will force
> all users options or force the ULIMIT in the init.d(bash) script.
>
> I would not try to run under bash a for loop that opens more then 512 FD
> in a case I want to stay sane.
>
> Eliezer
>
>
> On 09/16/2013 12:58 AM, Carlos Defoe wrote:
>> Seems right, Kinkie. "ulimit Provides control over the resources
>> available to the shell and to processes started by it". So that's why
>> squid process inherits the configuration made on the initialization
>> script. I assume that doesn't matter which user runs the subprocess.
>>
>> But limits.conf is a PAM feature. As you said, it should configure
>> limits on a system basis, for all users configured. What we are saying
>> is that it does not work at boot time, when squid runs. The
>> configuration on the init script is the only way to make it work.
>>
>>
>> On Sun, Sep 15, 2013 at 4:59 PM, Kinkie <gkinkie_at_gmail.com> wrote:
>>> On Sun, Sep 15, 2013 at 2:51 PM, Carlos Defoe <carlosdefoe_at_gmail.com> 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.
>>> Ulimits are inherited by all child processes; lowering them is always
>>> possible, raising them may be an administrator-only action.
>>> bash's manual (man 1 bash) has an informative chapter on ulimit.
>>> Otherwise you may want to check setrlimit(2).
>>> System-wide settings may be set in /etc/security/limits.conf (or
>>> /etc/limits.conf, depending on your distro). Man 5 limits.conf has the
>>> details (at least on my Ubuntu Raring system).
>>>
>>> Kinkie
Setting limits in limits.conf is the correct solution that works for OP.
Now we have answer "Why limits should be set for root, not proxy user?"
Because squid init script is started by init process which is owned by
root and inherits limits from it.
As a more precise solution (at least for ubuntu/debian) I see the way
used in nginx init script: https://www.ruby-forum.com/topic/4414498#1111291
Received on Mon Sep 16 2013 - 10:38:02 MDT
This archive was generated by hypermail 2.2.0 : Mon Sep 16 2013 - 12:00:11 MDT