tlaro...@polynum.com writes:
>> >But how to increase proc.curproc.rlimit.descriptors.{hard,soft}?
>But this is the problem: ulimit -n doesn't accept it either. So I
>concluded that the limit set by the kernel imposes, logically, a limit.
The hard limit is limited by the kernel limit.
The soft limit is limited by the hard limit
only root can raise the hard limit. For some reason, trying to
exceed the kernel limit is silently ignored.
E.g.:
$ ulimit -Hn
1772
$ ulimit -Sn
1024
$ ulimit -Sn 1772
$ ulimit -Sn
1772
$ ulimit -Sn 1773
ulimit: error setting limit (Invalid argument)
$ ulimit -Hn 2000
ulimit: error setting limit (Operation not permitted)
# sysctl -n kern.maxfiles
1772
# ulimit -Hn
1772
# ulimit -Hn 2000
# ulimit -Hn
1772
# sysctl -w kern.maxfiles=5000
kern.maxfiles: 1772 -> 5000
# ulimit -Hn
1772
# ulimit -Hn 2000
# ulimit -Hn
2000
# ulimit -Sn
1772
# ulimit -Sn 2000
# ulimit -Sn
2000
# ulimit -Sn 2001
ulimit: error setting limit (Invalid argument)
Since limits are inherited, changing the kernel limit doesn't do
anything unless you run a root process that raises the limit. Not
even new logins will help.
You could:
- configure /etc/login.conf with explicit limits
a new login should then set the new limits.
But this doesn't necessarily apply to graphical logins.
- set a new hard limit for the init process like:
sysctl -w proc.1.rlimit.descriptors.hard=2000
And then make init spawn a new tty session (already running
getty processes still have the old limit).
To get this on startup, it's not sufficient to set kern.maxfiles
in /etc/sysctl.conf. You need to set limits for proc.1 and for
the shell that runs the rc scripts. This can be done with a sourced
rc script.
>And:
>sysctl -a|grep descriptors
>only return proc.curproc...
Yes, the proc.$pid entries are hidden. Just try something like: sysctl proc.1
Greetings,
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
