Difference between revisions of "Ulimit Nofiles"
From Linux-VServer
(Created page with '= 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 t…') |
(→Step 2: becoming root) |
||
| (5 intermediate revisions by one user not shown) | |||
| Line 11: | Line 11: | ||
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. | 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. | 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 | + | 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 probably have a line like this in /etc/security/limits.conf: |
@staff hard nofile 32768 | @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. | + | 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 == | == Step 2: becoming root == | ||
| − | But wait! There is more! You are gaining root privileges, aren't you? And the tool that you | + | But wait! There is more! You are gaining root privileges, aren't you? And the tool that you use, 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: | 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 | 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. |
| + | |||
| + | == Aftermath == | ||
| + | If you are using debian or similar which have split configuration file directories, it helps to just create a file: | ||
| + | /etc/security/limits.d/nofiles.conf | ||
| + | With contents like: | ||
| + | # Allow mysql restart from ssh login | ||
| + | @staff hard nofile 32768 | ||
| + | root hard nofile 32768 | ||
Latest revision as of 21:32, 15 February 2012
Contents |
[edit] 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.
[edit] 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.
[edit] 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 probably 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
[edit] Step 2: becoming root
But wait! There is more! You are gaining root privileges, aren't you? And the tool that you use, 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
[edit] 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.
[edit] Aftermath
If you are using debian or similar which have split configuration file directories, it helps to just create a file:
/etc/security/limits.d/nofiles.conf
With contents like:
# Allow mysql restart from ssh login @staff hard nofile 32768 root hard nofile 32768
