myhand

Ну а почему не сразу на второй?

Что-ж тут красивого. И сама идея - так себе.. И использование конкретно FTP для этой цели - глупо.

Есть масса сетевых файловых систем, возьмите хоть NFS к примеру. Для Ваших целей ее должно вполне хватить, вместо "монтирования" всякой ерунды.

Ну так есть разница, когда апач сперва прибивает всех потомков и затем перечитывает конфигурацию, переоткрывает логи (это - может быть долго) и когда перечитывает конфигурацию, переоткрывает логи и уже потом запускает новых потомков, дождавшись отработки висящих запросов?

"Занимает" рестарт - время приблизительно одинаковое. Только эффект на клиентов оказывает разный.

Думаю, что давно пора. Не спешите удивить своими знаниями - подумайте сперва над тем, что Вам пишут ;)

На всякий случай - можно, конечно. Но сильно сомневаюсь, что крон задания какой-нибудь oom-killer поувивал, а ТС не заметил каких-либо проблем посущественней ротации логов ;)

Вы все слова в собственном-то посте поняли? В одном случае - имеем кучу отказов в обработке запросов. В другом - нет. Клиенты вообще такого рестарта не заметят, если MPM апача верно сконфигурирован.

myhand ничего подобного не утверждал. На время рестарта HUP или USR1 никак не влияет - и там и там перечитывается конфигурация полностью. Именно она определяет время рестарта.

Вам указывали на другое существенное различие.

PS: "myhand утверждал", что iHead читать не умеет. Теперь он сильно подозревает, что это неустранимый дефект изделия...

"Делаем". Только к "настройке райд" это уже никак не относится, в отличие от мониторинга райд. Согласны?

Нет, перезапускать не надо. В ином случае - я написал бы Вам.

Тогда почти наверняка - дело в этом.

Попробуйте добавить в logrotate.d/nginx строчку для reload апача:

/var/log/nginx/*log /var/www/httpd-logs/*log {

    daily

    rotate 10

    missingok

    notifempty

    compress

    sharedscripts

    postrotate

        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`

        /sbin/service httpd reload > /dev/null 2>/dev/null || true

    endscript

}

Хотя по-идее - это баг и не вам бы его исправлять...

Это не существенно. Просто еще один лог nginx со своим форматом.

Наиболее существенная. Обрабатывался запрос - а Вы раз и оборвали ему песню...

Ну, где взялась - там и положите. Никто кроме Вас ведь не ответственен за тараканов в Вашей голове ;)

Вот какие дела ;) Так что не обращайте внимание на то, что Вам пишут местные "гуру" про рестарты.

Вообще, без сильной нужды в конфиги logrotate лучше не лезть - все перезапускается именно так, как положено.

А, 00:28, понятно.

Речь о логах здесь: /var/www/httpd-logs/*log - верно? Тут лежат логи nginx прежде всего.

Могу предположить вот что. Посмотрите куда пишутся логи апача (в секциях VirtualHost /etc/httpd/conf/httpd.conf) и nginx (в /etc/nginx/nginx.conf). Если это одни и те же файлы - дело швах и это "чудо" (ispmanager) до сих пор ничему не научилось :)

Тогда Ваша проблема наверняка в этом.

Опять спешим с советами? :)

Если дело именно в том, о чем я написал выше - логичнее бы открыть баг в ispmanager, а не делать персональный костыль.

Думаю, я сказал вполне достаточно.

чОткий ответ, что тут скажешь. Вы тут самый главный телепат, даже не подумаю спорить.

Может у него как у поэта: "я достаю из широких портовштанин, дубликатом бесценного груза..."?

http://httpd.apache.org/docs/2.2/en/stopping.html

Риторический вопрос: может советы давать не надо, предварительно не "ознакомившись" с, извините, элементарной информацией?

На основании чего вдруг? Не думаю, что эмоциональная классификация Ваших знаний что-то существенное добавляет к перечисленным мною Вашим ошибкам.

Вот неумение читать - таки да, существенно.

И не мечтайте.