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 <aaron.cline_at_gmail.com> 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
Received on Fri May 13 2016 - 18:59:31 UTC