The setting is not controlled by monit. The limits.conf setting is PAM related - monit starts as system service and there's no session => the limits.conf is not evaluated. If you want to rise the filedescriptors limit, you can create monit startup script which will first set the ulimit and then start monit.
limits.conf manual page excerpt: --8<-- Also, please note that all limit settings are set per login. They are not global, nor are they permanent; existing only for the duration of the session. --8<-- Regards, M/Monit support On Mon, Apr 12, 2010 at 11:33:51AM -0400, Mike Oliveras wrote: > I have a SIP application that requires a lot of UDP ports, so the nofile > parameter was increased in the limits.conf file. My Machine is running > Centos 5.4. I am running monit 5.1.1 from inittab as follows: > > # Run monit in standard run-levels > mo:2345:respawn:/usr/bin/monit -Ic /etc/monitrc > moff:06:wait:/usr/bin/monit -Ic /etc/monitrc stop all > > > My monit.rc file starts up the program as another user. > > # Test SBC > check process testsbc with pidfile /home/test/sbc/data/testsbc.pid > start program = "/etc/init.d/testsbc start" > as uid testsbc and gid testsbc > stop program = "/etc/init.d/testsbc stop" > as uid testsbc and gid testsbc > > When monit tries to start testsbc, it fails with errorno=24 (too many files > open). > > If I run the init script directly as the "testsbc" user then it runs without > issue. > > If I execute ulimit -n from either the root or testsbc user, it does > correctly display the nofiles as my increased limit. > [r...@qatestbed sbc]# ulimit -n > 65535 > [r...@qatestbed sbc]# > [r...@qatestbed sbc]# su - factor > [test...@qatestbed ~]$ ulimit -n > 65535 > > Anyone experience this before? I was going to open a bug report but wanted > to check first if I was just missing some configuration or something. > > Thanks, > > Mike > -- > To unsubscribe: > http://lists.nongnu.org/mailman/listinfo/monit-general -- To unsubscribe: http://lists.nongnu.org/mailman/listinfo/monit-general
