[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

start-stop-daemon ignoring limits

Hi, I am Debian user for 3 years, using it mostly for high-loaded servers,

and I am really worried about one serious problem with start-stop-daemon.


This problem was introduced in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302079,

but it seems that in 2005 this problem was forgotten. For 7 years nobody seems to care about it,

but now, when servers become much more powerful, we MUST have a system-wide

mechanism for setting limits from /etc/security/limits.conf for daemons.


For example, on my production servers, I am setting high 'nofile' limits for

Redis-server, RabbitMQ, Pgbouncer and Postgres. And now the only way to set limits

for daemons is calling ulimit from their init scripts, which is a kind of hack, because values

in init scripts does not correspond with system-wide settings in limits.conf.


The first way to fix this problem was to parse configuration file in start-stop-daemon,

as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=302079.


The second way is to use PAM mechanism and configure some pam service to use pam_limits.so,

and a patch was made in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376165 to fix other

problem - setting variables for daemons. This patch was reverted, because

"When start-stop-daemon starts a daemon, it cannot closes the PAM session,

or the session will be closed before the daemon quits"


But, for example, in RHEL6 they use runuser, which is just a part of su,

and it uses just the same pam mechanism as was introduced in patch for bug 376165.

I've made a simplified version of 376165 patch, and tested it on Squeeze, and everything worked like a charm.

So, I'd like to ask, what must be done to add support for system-wide limits setting in start-stop-daemon?

I am certainly sure, that now we NEED to upgrade start-stop-daemon, and I don't care which way

(parsing a config file or using pam) will we choose, but something must be done, because this problem

slows Debian progress in becoming best server distribution.

Reply to: