linux - это не дистрибутив.
Отучаемся говорить за всех - все на Вас не похожи.
Опять таки, не судите о других по себе.
Это Вам может "не нужно" поддержка InfiniBand, а мне нужно. И еще много чего нужно в этой связи.
Вы тоже еще не выросли из возраста когда кричат "маздай" про продукты Microsoft? А я не вижу особой разницы с другим коммерческим ПО. Право же, возможность сообщить разработчикам о проблеме (причем сделать нормальный багрепорт) - вовсе не так уж и плохо. Не хотите такое делать - не делайте. Отключите это, наконец.
Да динозавр как раз. В области виртуального хостинга ее еще можно, наверно, использовать наряду с Linux. Во всем остальном - она аутсайдер (или вообще неработоспособна как решение).
Вот-вот. Именно что надо. Например что такое su и чем отличается su -m apache от обычного запуска апача из init-скрипта.
fsbackup, rsnapshot
В инит скрипте.
Например, в Debian - инит скрипт апача берет переменные окружения из /etc/apache2/envvars. В т.ч. и информацию для ulimit. И применяет это перед запуском. В centos аналогично, а если таки подобной возможности штатно нет - просто отредактируйте инит скрипт и поставьте там вызов ulimit перед стартом апача.
Двойка.
Вполне возможно, что ситуация, которую я описал выше - была актуальна еще для версии из etch (судя по версии апача - у Вас Debian Etch).
PS: Это оффтопик тут, но я бы посоветовал подумать над обновлением. Etch уже давным давно не поддерживается.
Что за система? Какая версия апача?
До непомню какой (в 2.0 ветке) версии - апач ходил прибивать своих детей с GET /, а не OPTIONS *. Этим скорее всего объясняется количество GET / в пустых слотах.
Так что по данному статусу сложно судить о причине проблемы. Видно, что число апачей сильно увеличилось. Что было тому причиной - возросшая нагрузка, плохая связность (nginx может помочь), кривой скрипт... ХЗ.
Установите мониторинг, monit например. И настройте его, чтобы в период нагрузки он дал Вам нужную статистику (ps, top, netstat, wget ... server-status).
Обращайтесь, если что.
+2
чтобы уйти от оффтопика, может ответите на вопрос, заданный уже давно:
Не можно, а нужно. И не абы когда, а тогда - когда это действительно нужно. Вы не поверите, но > 50% случаев обращений это на самом деле не нужно, а можно без лишней волокиты ответить на письмо клиента.
Надо не "смотреть", а понимать при этом что Вы видите.
Nanotik, давайте не разводить оффтопик, тем более что знаний у Вас маловато.
К сожалению, не все так просто.
"С какого email" - не авторизует клиента (ну разве что Вы договоритесь с клиентом, что он будет слать письма "воон с того почтового сервера", а Ваша техподдержка скрупулезно анализировать их технические заголовки).
Так что, если Вы хотите ему сообщить конфеденциальную информацию - этого мало. Потому я и написал про "запрос из панели управления" (Ваш интерфейс к тикет-системе, который позволяет отправить авторизованный запрос) или GPG-подпись.
С Nanotik уже все понятно - "чукча не читатель". Но Вы, я думал - более подготовлены и внимательны.
Они самые. Как минимум: обучить их сообщать конфеденциальную информацию только по авторизованной заявке - куда проще чем научить разбираться в том откуда кто и как отправил email.
Во-первых - Дебиан. А во-вторых, Дебиан != Linux. Ядро FreeBSD там поддерживается уже официально.
Так что Вас не должна заботить "моя направленность". Если назовете что-то, пришедшее из FreeBSD в Linux - думаю, будет интересно.
PS:
Дальше Ваш пост уже не читал - на этом потоке сознания можно мозги свернуть.
Что "не закрыть" - возможность выполнения PHP-кода? PHP shell - это не жупел, а просто PHP-код. Абсолютно никак не отличающийся от других скриптов клиента. Вы можете ограничить его функциональность, запретив определенные функции. Попутно поломав и другие скрипты клиента, которые их используют.
