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 via email to