Thorsten Büker wrote: > Hi together, > > aroused by its reconfiguration (integration of Opcode APC) an Apache, > running inside a VServer, suffers from to many open files: > > Apr 30 15:40:49 hostname kernel: grsec: From 134.130.85.167: denied > resource overstep by requesting 1024 for RLIMIT_NOFILE against limit > 1024 for /vservers/web/usr/bin/php4-cgi[php4-cgi:23500] > uid/euid:1111/1111 gid/egid:1111/1111, parent > /vservers/web/usr/sbin/apache2[apache2:2773] uid/euid:0/33 gid/egid:33/33 > > Raising the permitted number of open files by the following steps didn't > work as I expected. Beside adding the bcapability SYS_RESOURCE in the > VServer's configuration I amended the subsequent lines to the Vserver's > /etc/security/limits.conf (with vhost-user representing the uid 1111 > from above): > > root soft nofile 1536 > root hard nofile 1536 > vhost-user soft nofile 1536 > vhost-user hard nofile 1536 > www-data soft nofile 1536 > www-data hard nofile 1536 You don't really want to give the guest CAP_SYS_RESOURCE... If you haven't limited the guest already in /etc/vservers/<guest>/ulimits/nofile*, pam should be able to set those limits (with recent utils). > Entering the VServer's context by "vserver web enter" and asking for > information by "ulimit -a" for root still returns: > > [...] > open files (-n) 1024 > [...] As expected, it's not using pam. See above. > Proceeding to user www-data or vhost-user delivers the expected results: > > web:/etc/security# su www-data -c "ulimit -a" > [...] > open files (-n) 1536 > [...] ... since this does use pam. > Increasing the permitted number of open files for root on the hostsystem > outside the VServer's context leads to a higher number inside the > Vserver, too. But as there's no user with uid 1111 on the hostsystem, so > this approach doesn't help. Doesn't matter. pam on the host has nothing to do with it, _if_ you configure your guest correctly. The fact that you inherit root's ulimit on the host is simply because you didn't tell the utils to do anything, so they don't. > The kernel configuration of VServer 2.6.22.16-grsec2.1.11-vs2.2.0.6, > used in combination with backported util-vserver 0.30.210-8bpo2, looks > as follows: Upgrade your utils, and your kernel. Both are known to be problematic. > CONFIG_VSERVER_LEGACY=y > # CONFIG_VSERVER_LEGACY_VERSION is not set > CONFIG_VSERVER_DYNAMIC_IDS=y > CONFIG_VSERVER_LEGACYNET=y > # CONFIG_VSERVER_REMAP_SADDR is not set > CONFIG_VSERVER_COWBL=y > # CONFIG_VSERVER_VTIME is not set > CONFIG_VSERVER_PROC_SECURE=y > # CONFIG_VSERVER_HARDCPU is not set > # CONFIG_TAGGING_NONE is not set > # CONFIG_TAGGING_UID16 is not set > # CONFIG_TAGGING_GID16 is not set > CONFIG_TAGGING_ID24=y > # CONFIG_TAGGING_INTERN is not set > # CONFIG_TAG_NFSD is not set > # CONFIG_PROPAGATE is not set > CONFIG_VSERVER_PRIVACY=y > CONFIG_VSERVER_CONTEXTS=256 > CONFIG_VSERVER_WARN=y > CONFIG_VSERVER_DEBUG=y > CONFIG_VSERVER_HISTORY=y > CONFIG_VSERVER_HISTORY_SIZE=64 > # CONFIG_VSERVER_MONITOR is not set > CONFIG_VSERVER=y > > > Is there any clue I'm missing? Any hints appreciated, thanks! > > kind regards, > Thorsten > -- Daniel Hokka Zakrisson