Original bug description is incorrect, limits defined in /etc/security/limits.conf have no bearing on services started by sysvinit in CentOS or upstart in Ubuntu.
For example, in Debian (and Ubuntu) packages for Apache, limits can be set by uncommenting this line in /etc/apache2/envvars (honored by apachectl):
APACHE_ULIMIT_MAX_FILES='ulimit -n 65536'
On CentOS, there's no corresponding option since the init script doesn't use apachectl. Corresponding ulimit commands will have to be patched directly into the init script in the httpd package. Likewise for Ceph (including RadosGW) on CentOS, upstream init scripts include hardcoded ulimit commands: https://github.com/ceph/ceph/blob/firefly/src/init-radosgw.sysv#L83
Original bug description is incorrect, limits defined in /etc/security/ limits. conf have no bearing on services started by sysvinit in CentOS or upstart in Ubuntu.
According to Debian Wiki, every service is responsible for setting its own limits: /wiki.debian. org/Limits
https:/
For example, in Debian (and Ubuntu) packages for Apache, limits can be set by uncommenting this line in /etc/apache2/ envvars (honored by apachectl): ULIMIT_ MAX_FILES= 'ulimit -n 65536'
APACHE_
A more generic solution on Ubuntu is to use "limit nofile" upstart option like this: /github. com/ceph/ ceph/blob/ firefly/ src/upstart/ radosgw. conf#L9
https:/
On CentOS, there's no corresponding option since the init script doesn't use apachectl. Corresponding ulimit commands will have to be patched directly into the init script in the httpd package. Likewise for Ceph (including RadosGW) on CentOS, upstream init scripts include hardcoded ulimit commands: /github. com/ceph/ ceph/blob/ firefly/ src/init- radosgw. sysv#L83
https:/