I need to to change the ulimit to 16384(ulimit -n 16384) on boot on Centos 5.4 64 bit. How do I do that? Been searching and have yet to find a good answer. Tried to do it in rc.local but it appears to happen to late there.
Matt
I need to to change the ulimit to 16384(ulimit -n 16384) on boot on Centos 5.4 64 bit. How do I do that? Been searching and have yet to find a good answer. Tried to do it in rc.local but it appears to happen to late there
In order to make the change permanent, add the following line to "/etc/security/limits.conf":
* - nofile 16384
From "limits.conf"'s header:
«Quote:
- the wildcard *, for default entry - nofile - max number of open files
I need to to change the ulimit to 16384(ulimit -n 16384) on boot on Centos 5.4 64 bit. How do I do that?
After replying to you, I tested the "solution" I gave you and it didn't work.
I found a working solution. I added the following line to /etc/profile:
ulimit -n 16384
This works as the general default setting. If you want to apply the setting to a particular user, you should add it to the .bash_profile file in the user's home directory.
I know it works because I just tested it and it survived the server's reboot. I ran "ulimit -a" and the new value was there.
Please excuse me for the involuntary mislead. I was pretty sure that it did work "once upon a time"...
On Sun, Apr 11, 2010 at 03:25:47AM +0100, Miguel Medalha wrote:
I need to to change the ulimit to 16384(ulimit -n 16384) on boot on Centos 5.4 64 bit. How do I do that?
After replying to you, I tested the "solution" I gave you and it didn't work.
I found a working solution. I added the following line to /etc/profile:
ulimit -n 16384
It's not clear from the OP's original post whether this will work for his purposes or not. My guess (which I can't substantiate, since I don't have a box which I can reboot to test) is that the entry in /etc/profile may not be applied to the init scripts, so (for example) if he wanted httpd limited the /etc/profile entry may not be sufficient.
Matt, perhaps you could provide more details, on which processes you desire to have this ulimit, and why. The more specific you can get the better quality answers you'll receive.
I know it works because I just tested it and it survived the server's reboot. I ran "ulimit -a" and the new value was there.
...from a login shell. If you don't have a login shell /etc/profile isn't read on bash startup.
--keith
I know it works because I just tested it and it survived the server's reboot. I ran "ulimit -a" and the new value was there.
...from a login shell. If you don't have a login shell /etc/profile isn't read on bash startup.
In my case, I am doing the change because of Samba. When you run tesparm, the lastest versions of Samba give the following warning:
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
When I add the line "ulimit -n 1024" to /etc/profile, the warning disappears, even after a reboot. So, this certainly works for processes running as root.
But you are right in that it will probably depend on the particular user requirement.
I know it works because I just tested it and it survived the server's reboot. I ran "ulimit -a" and the new value was there.
...from a login shell. If you don't have a login shell /etc/profile isn't read on bash startup.
In my case, I am doing the change because of Samba. When you run tesparm, the lastest versions of Samba give the following warning:
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
When I add the line "ulimit -n 1024" to /etc/profile, the warning disappears, even after a reboot. So, this certainly works for processes running as root.
But you are right in that it will probably depend on the particular user requirement.
I also had to increase the default ulimit to 8192 on my ldap servers otherwise people couldn't login.
On Sun, Apr 11, 2010 at 03:49:04PM +0100, Miguel Medalha wrote:
In my case, I am doing the change because of Samba. When you run tesparm, the lastest versions of Samba give the following warning:
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
When I add the line "ulimit -n 1024" to /etc/profile, the warning disappears, even after a reboot. So, this certainly works for processes running as root.
It's not related to root/nonroot. If you run these things when logged in, /etc/profile has been read in, so your subprocesses all inherit the ulimit. On boot, it's not clear to me whether /etc/profile is read, since I would guess that's not a login shell. (I suppose you could also test this via cron or at, since IIRC those programs do not provide a login shell either (unless asked for?).)
But you are right in that it will probably depend on the particular user requirement.
In any case, if surviving the boot process is desired, the changes should specifically be tested at boot, not just from a root login shell. This issue trips up even seasoned administrators (*ahem*).
--keith
In my case, I am doing the change because of Samba. When you run tesparm, the lastest versions of Samba give the following warning:
In any case, if surviving the boot process is desired, the changes should specifically be tested at boot, not just from a root login shell. This issue trips up even seasoned administrators (*ahem*).
--keith
Agreed, I put mine in the rc startup script for ldap. I would suggest only putting into what ever process needing it vs a system wide var.