Does chpst honour ulimit settings?

Question

We are currently experiencing issues with a JBoss-based server on a linux platform - effectively, we are running out of available file-handles within the process, and the server croaks.

We have set ulimit to permit 10000 open filehandles, and the server is consistently crashing when far fewer filehandles are open.

The one thing I've noticed is that our startup scripts use chpst, and I noticed that chpst permits you to set file / process / memory limits as arguments. Does anyone know whether chpst honours the existing system ulimit if no explicit commands are set, or does it use its own internal defaults? If so, where would I find these?

thanks

Answer 1

chpst does not even honour what you pass as arguments. The source code is really hard to read, but strace confirms:

execve("/usr/sbin/chpst", ["chpst", "-o", "10000", "/bin/sh", "-c", "sleep 5"], [/* 26 vars */]) = 0
...
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=4*1024}) = 0
setrlimit(RLIMIT_NOFILE, {rlim_cur=4*1024, rlim_max=4*1024}) = 0
execve("/bin/sh", ["/bin/sh", "-c", "sleep 5"], [/* 26 vars */]) = 0
...

I would avoid.

Answer 2

Can't add comment to Olivier Tharan, and even if this is an old question, I think it's not bad to correct wrong assertions (especially if assertion is relatively recent).

In his strace, getrlimit says the maximum hard limit is 4096, and he asks chpst to set the soft limit to 10000. chpst does so, but as documented in mangage of limits.conf, soft limits can not exceed hard limits, which are enforced by kernel and root user. The only thing one could say about that, is that maybe chpst should print a warning, that's all. Certainly not "I would avoid".

Note that this means the original problem might not be related to chpst, but to the system's configuration. chpst is only a tool to set arbitrary limits to a single process, it's not a tool to configure kernels.