On Sat, Feb 07, 2009 at 12:14:11PM -0300, Bruno Galindro da Costa wrote: > Hi all > > I'm have a Sun v240 Sparc64. I've installed recently a Debian 4.0 > RC6 (Etch) plus Linux VServer kernel. The following comands i used to > build VServer: > Commands on the host machine: > # apt-get -y install ssh linux-image-vserver-sparc64 util-vserver > linux-headers-2.6.18-6-vserver-sparc64 debootstrap vserver-debiantools > # reboot > # uname -a > Linux dmzux001 2.6.18-6-vserver-sparc64 #1 SMP Fri Dec 12 19:06:09 UTC 2008 > sparc64 GNU/Linux > # vserver mx001 build -n mx001 --hostname mx001.domain.com.br --interface > eth0:172.20.0.21/24 -m debootstrap -- -d etch > # ulimit -HS -n 65536 > # ulimit -Ha > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) unlimited > max nice (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 65536 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) unlimited > max rt priority (-r) 0 > stack size (kbytes, -s) unlimited > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > # echo '* - nofile 65536' >> /etc/security/limits.conf > # echo "default" > /etc/vservers/mx001/apps/init/mark > # echo 'CAP_SYS_ADMIN' > /etc/vservers/mx001/bcapabilities ~~~~~~~~~~~~~~~~ you definitely do not want to give that to a guest lightly why? because the guest can easily mess up the host now, and that's probably not what you want (see big fat red warning, here: http://linux-vserver.org/Capabilities_and_Flags) > # echo 'CAP_SYS_RESOURCE' > /etc/vservers/mx001/bcapabilities ~~~~~~~~~~~~~~~~~~~ similar here, usually no need for > # echo 'SET_RLIMIT' > /etc/vservers/mx001/ccapabilities > # vserver mx001 start > # vserver mx001 enter > Comands on guest machine after postfix installation: > # uname -a > Linux mx001.domain.com.br 2.6.18-6-vserver-sparc64 #1 SMP Fri Dec 12 > 19:06:09 UTC 2008 sparc64 GNU/Linux > # ulimit -HS -n 65536 > # echo '* - nofile 65536' >> /etc/security/limits.conf > # ulimit -n > 65536 > # ulimit -Ha > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) unlimited > max nice (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) unlimited > max locked memory (kbytes, -l) unlimited > max memory size (kbytes, -m) unlimited > open files (-n) 65536 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) unlimited > max rt priority (-r) 0 > stack size (kbytes, -s) unlimited > cpu time (seconds, -t) unlimited > max user processes (-u) unlimited > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > The guest builded above, will be a mail server. The MTA is Postfix > version 2.3.8. > > The followig error is occurring when postfix service is started "ONLY" > in two situations: on guest / host boot and/or when the ulimit -n is > 1024. But if you can see above, I've set the ulimit -n to 65536 on the > host and guest machines. > *postfix/cleanup[5324]: fatal: setrlimit: Operation not permitted* > If I restart Postfix service *after* the above error is printed to > /var/log/mail.log, the error does not ocurr anymore until the next > restart of the guest machine or host machine. well, you kind of answered your question yourself, you are setting the host limit very high, but only when you logon, the very same is tried inside the guest, but there it fails, when the host limit is below the value you try to set > Can anyone help me? the correct solution is to put the guest ulimits into the guest config tree, to have them applied when the guest is started. (see http://www.nongnu.org/util-vserver/doc/conf/configuration.html) look for ulimits, adjust them correctly, remove the additional bcapabilities (to make the guest safe again) and you should be fine ... no need to have the limit raised on the host though, but it doesn't hurt either ... > Sorry my poor english. english isn't my primary language either, and it was more than sufficient to understand what you meant ... best, Herbert > -- > Att. > Bruno Galindro da Costa > bruno.galindro@gmail.com > Florianópolis - SC