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@xxxxxxxxx> wrote:
On Sun, Sep 15, 2013 at 2:51 PM, Carlos Defoe <carlosdefoe@xxxxxxxxx> 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
