It might appear to do so if you try with a /etc/init.d/apache2 start, because then it is started by the shell (and thus inherits its limits and audit session) but it doesn't work that way when started from the RC system at boot up. The reason is simple: it doesn't pass through start-stop-daemon. While s-s-d has still trouble supporting per-user limits, it at least applies general limits from /etc/security/limits.conf if configured with PAM, but ignoring it will cause no further limits to be applied. Simply change the start command to start-stop-daemon --start --pidfile "${PIDFILE}" ${APACHE2} -- ${APACHE2_OPTS} -k start and it'll work just fine. Security feel free to pick this up if you wish to do so.
Should be fixed through bug 365149
Christian I think apache init script does not use ssd, the patch to fix this issue is applied at bug 364453. Or what do I miss?
Thank you for report. Fixed in apache-2.2.21.
I have just updated from 2.2.20 to 2.2.21, and couldn't start apache anymore: l8xsvn ~ # /etc/init.d/apache2 restart * Starting apache2 ... /sbin/start-stop-daemon: need at least one of --exec, --pidfile, --user or --name Try `/sbin/start-stop-daemon --help' for more information. [ !! ] l8xsvn ~ # I suspect that the new s-s-d syntax used in the init script does not work on my machine as I'm still running on baselayout-1 (due to old xen kernel). Supplying the --exec parameter makes it work. However, this is certainly a regression that shouldn't have happened, even though baselayout-1 isn't supported anymore (is it? at least it's not in the tree anymore). So what would be the correct way to fix this? Use the old s-s-d syntax? Make apache depend on a new baselayout just because of the init script? Both don't really sound good to me.
Right, its because of baselayout-1.
Tobias what is the reason to keep baselayout-1? Personally I have no means to test this init script with it and I'd let baselayout-1 die. You can keep old init script since init.d directory is config-protected. In any case, please, comment in bug 383957. This one is fixed.