Миграция веб-сервера это такое мероприятие, ... в общем стремное это мероприятие, тем более стремное, чем больше виртуальных хостов на этом сервере находится. Но понимаешь что надо, тот самый момент, когда оттягивать миграцию дальше некуда, потому что обнаружен баг в fcgi+rails+apache на freebsd, который толком и лечить не знают как. И поэтому посчитали этот баг на багом, и фиксить, в общем, его никто не собирался. 

Какой выход? Даже если вас съели - у вас есть два выхода, также и в нашем случае.

Есть такая связка, mongrel + apache. Отличная, надо сказать, связка, на нее перешли с fast_cgi отцы - основатели Rails (rubyonrails.org), а это, знаете ли, хорошая примета. Только вот проблема - апач у нас не 2.x, а 1.3.x. Вот  откуда появилась потребность в миграции, а потом еще  когда-то хотелось subversion с webdav. Одним словом момент для миграции был самый что ни на есть подходящий. Поэтому руки сами собой потянулись в /usr/ports/apache22, и, как потом оказалось, зря.

И что у нас с портами? А-а-а, отлично у нас с портами, там одних мейкфайлов три штуки.  Итак, нам потребуются: mod_proxy, mod_proxy_balancer, web_dav, suexec (для запуска сайтов под конкретными пользователями). Это все страшно на вид, а на самом то, на деле, все вышесказанное сводится к таким командам:

pkg_deinstall apache

cd /usr/ports/www/apache22 

make WITH_PROXY_MODULES=yes WITH_SUEXEC_MODULES=yes SUEXEC_DOCROOT=/www

make install

на самом на деле все изменения в конфигурационных файлах  виртуальных хостов свелись к замене

User myuser
Group mygroup

на

SuexecUserGroup myuser mygroup 

Остальные манипуляции касались перехода с fastcgi на mongrel.

Однажды потребовалась настройка ограничении на процессы апача. Вот как она делается:

login.conf: 

# WWW apache limits login group
www:\  
        :maxproc-max=256:\
        :maxproc-cur=256:\
        :datasize-max=256M:\
        :datasize-cur=64M:\
        :openfiles-cur=768:\
        :stacksize-cur=4M:
 

cap_mkdb /etc/login.conf

проверяем:

limit -C www:

Resource limits for class www:
  cputime          infinity secs
  filesize         infinity kb
  datasize-cur        65536 kb
  stacksize-cur        4096 kb
  coredumpsize-cur        0 kb
  memoryuse        infinity kb
  memorylocked     infinity kb
  maxprocesses          256
  openfiles-cur         768
  sbsize           infinity bytes
  vmemoryuse       infinity kb

таким образом навесить эти ограничения на процесс апача мы можем двумя способами:

1. Непопосредственно на логин www в /etc/passwd

www:*:80:80:www:0:0:World Wide Web Owner:/nonexistent:/sbin/nologin

где после 80:80 www как раз и означает класс логина. 

2. Или же в rc.conf через rc-ng стиль:

apache22_enable="YES"
apache22limits_enable="YES"
apache22limits_args="-e -C www"

 А на следующий день я трахался. Много и часто трахался так и эдак пересобирая апач в связи с процессами-зомби порождаемыми апачем. Сервер уходил в состояние, в котором не мог форкнуть ни одного процесса, в т.ч. что-либо в шелле, поэтому помогал только кардинальный ребут.  Открыл для себя команды strace и pstree, много смотрел в процессы. Стало ясно, что все дело в управлении порождением дочерних процессов апачем, а именно MPM, - новой апачевой фичей, которая по умолчанию была указана в prefork. Да, работал prefork, и это было очень заметно по количеству висящих зомби-процессов. В апаче 2.2.3 невозможно выключить MPM. Кю.

А вот и решение проблемы: 

Снес я апач 2.2.3 , поставил 2.0.59 и зажил долго и счасливо.

Только омрачало немного отсутствие в 2.0.59 mod_proxy_balancer. Победилось такими строками проксировиния виртуального хоста от апача к монгрелу:

было:

<Proxy balancer://zagorod_cluster>
    BalancerMember http://127.0.0.1:8000
</Proxy>
<virtualhost>
...
  ProxyPass / balancer://zagorod_cluster/  ProxyPassReverse / balancer://zagorod_cluster/
...
</virtualhost>

стало:

<virtualhost>
 ProxyPass / http://127.0.0.1:8000/   
 ProxyPassReverse / http://127.0.0.1:8000/
</virtualhost>

Спасибо, бразерам komar и brj, за непосредственный хелп.