Re: Setting open files for a process started by runit (using chpst)

From: Tony Gaetani <>
Date: Fri, 13 May 2016 20:59:31 +0200

I think chpst -o can only limit open files meaning reduce the number of
open file descriptors for the process, not increase. I'm just speaking
from memory, I have no proof to back up this conjecture. I recommend
using ulimit -n in your run scripts per services, rather than on runsv

On 5/13/16 20:54, Colin Booth wrote:
> On Fri, May 13, 2016 at 8:57 AM, Aaron Cline <> wrote:
>> Hello:
>> We have servers that use runit to manage our deployed processes (tomcat and
>> logstash). We had some issues with having too many open files in our
>> tomcat processes and so we're trying to increase the limit. I'm using the
>> /proc/<PID>/limits file to check to make sure the limits are increased.
>> We've tried increasing the limits in /etc/security/limits.conf, but that
>> didn't seem to work for the runit processes. Then I found the chpst man
>> page and started adding the -o option with a higher open files number
>> there, but that also doesn't seem to increase the number for neither the
>> tomcat or logstash process according to the proc filesystem.
>> Is there some other gotcha I'm missing here?
> From the bit of experimenting that I did, it looks like chpst cannot
> currently (or never could, not sure) change hard limits. Presumably
> the default hard limit for logstash is too low, so even if you were
> bumping the limit with chpst, it was getting cut off at the hard limit
> value. If you're running your run script initially as root you can use
> ulimit within the script, something like:
> ulimit -n unlimited
> chpst -u user-to-change-to -o real-limit prog
> Or, if you're worried about logstash going berserk and eating all the
> available open fds since non-privileged users can increase the soft
> limit up to the hard limit, ulimit -n biggervalue will adjust both the
> hard and soft limits, letting you omit chpst's -o option entierly.
> Cheers!

Received on Fri May 13 2016 - 18:59:31 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC