|
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. |