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
itself.
On 5/13/16 20:54, Colin Booth wrote:
On Fri, May 13, 2016 at 8:57 AM, Aaron Cline <[email protected]> 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!
--
https://tonygaetani.com
