Difference between revisions of "Ulimit Nofiles"
From Linux-VServer
(→Step 1: your login) |
(→Step 3: wait, what?) |
||
| Line 21: | Line 21: | ||
root hard nofile 32768 | root hard nofile 32768 | ||
== Step 3: wait, what? == | == Step 3: wait, what? == | ||
| − | I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling. | + | I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't, at least not on my system. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling. |
Revision as of 12:02, 15 February 2012
Contents |
Increasing ulimit nofiles without CAP_SYS_RESOURCE
To increase the openfile descriptor limit in a vserver you must understand one thing: on a normal server uid=0 is allowed to do everything. Whatever you do, root is always allowed to say "override all security" on the most secure OS ever. Then comes vserver, and it takes all those rights away. Root is a mere mortal now with some added priviliges. One of those rights taken away is CAP_SYS_RESOURCE, which gives the right to override the hard limits set, and increase them. Without that right, constructions will fail if not taken into account for.
Step 0: the case
You are an admin, you want to log into a server and then restart a service. That service needs raised limit on open file descriptors.
Step 1: your login
Most people log into a vserver using ssh as an administrator. Ssh uses pam. And pam sets your *hard* limit. The default usually is 1024. Well, that's not a problem on normal systems, because once you gain root, you gain the right to ruin everything. This time you won't. The ceiling is set by pam, and you cannot raise it anymore. Whatever you do now, you won't be able to raise it. So we need to set that: in your vserver the pam limits configuration must be set for whatever you login to. On a debian system you should proably have a line like this in /etc/security/limits.conf:
@staff hard nofile 32768
This means that everyone in the administrator group staff gets a hard limit of 32768 when logging in or doing whatever. You can check that with:
ulimit -Hn
Step 2: becoming root
But wait! There is more! You are gaining root privileges, aren't you? And the tool that you uses, usually uses pam limits, to set limits for everybody, including root! So as an administrator you got a hardlimit of 32768, and once you're root, you still lowered to 1024. Yes, we must add root as a mere mortal to the limits.conf:
root hard nofile 32768
Step 3: wait, what?
I thought there was a step 3: setting a hard limit in /etc/vservers/*/ulimits/nofiles.hard , but there isn't, at least not on my system. This is probably because the normal hard resource limit is inf. But for every default hardlimit of a resource you need raised, you should put that in the vserver configuration, which will raise the ceiling, and probably add those to limits.conf to prevent lowering the ceiling.
