Re: Ulimit problem - CentOS 5.10

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Wed, Apr 23, 2014 at 5:19 PM, Nathan Duehr <denverpilot@xxxxxx> wrote:

> Running across some curious stuff with ulimit on CentOS 5.10.
>
> We have a non CentOS packaged version of Asterisk (using their packages)
> that we start at boot time with a typical RC script.
>
> Recently it started whining that it couldn't open enough file handles.
>
> As we dug further into this, it appears that at boot time, it inherits
> ulimit from init, which is pretty low: 1024.
>

Yep, it's rather low.


>
> We've set /etc/security/limits.conf and sysctl significantly higher both
> for root/system wide and also for the user Asterisk runs under, to no avail.
>

I've had success making changes in limits.conf (for MySQL in my case).
In my case I increased both the system wide and per user (mysql user).

Example:
<my_user> hard nofile 2048
<my_user> soft nofile 2048

SSH to that box (as <my_user>) ... run ulimit -Hn and -Sn ... bingo 2048

Are you able to switch users to the user your Asterisk user to run `ulimit
-Hn` and `ulimit -Sn`?
Once you've verified new sessions get the proper limits, stop and then
start your Asterisk daemon.  Hopefully from there it will stop whining
about file handles.


>
> If we log in via ssh as root (or sudo) the correct root/system-wide ulimit
> of 8192 is set.
>
> Looking in /proc/[PID]/limits shows the lower ulimit only if the package
> is started from init (standard rc3.d type sysV stuff...).  If we restart it
> via console, remote ssh, anything else, the limit bumps to 8196.
>

Interesting - I've not seen that odd behavior.  It worked across the board
(initscript and all) when I made changes via limits.conf.


>
> Attempting to force the ulimit up inside the RC script has no effect,
> since the package is running as a non-root user.  It fails to raise the
> limit.
>
> Right now, we're not totally against just taking it out of the startup and
> starting it manually anyway, since we really don't want the Asterisk
> platform coming up after a crash/reboot anyway, and any other reboots there
> will always be a human involved, but the way init is handling ulimit seems
> utterly retarded and broken.
>
> Some indication (different engineer found it, I haven't seen the RHEL case
> number) appears to indicate that folks wanted init ulimited heavily in case
> of startup DDoS type stuff, but we haven't figured out a semi-sane
> unix-conventional type way AROUND this when it's needed that if we were hit
> by the proverbial bus, a "normal" unix guy would find.
>
> Perhaps we're missing something.
>
> Thoughts?
>
> --
> Nate Duehr
> denverpilot@xxxxxx
>
>
>
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>



-- 
---~~.~~---
Mike
//  SilverTip257  //
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos




[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux