apache в KVM перестаёт принимать соединения. куда копать?

идеи?

yum update -y

1) искать причину подземных стуков сложно. Какую систему мониторинга используешь? Включи мониторинг всех возможных параметров. Ну там число сокетов, shared memory и т.п. Если на каком-нибудь графике заметишь корреляцию с проблемой, может появятся идеи.

2) При перезапуске apache ты проверяешь что он на самом деле завершился и перестал слушать порт? Может скрипт не отрабатывает

3) Перевесить на другой порт пробовал?

4) ( в порядке бреда ) натрави на логи апача и nginx хотя бы logwatch, а лучше какой-нибудь IDS. Может тебе кто-нибудь пытается сделать гадость

ipcs -s|grep apache

первое что сделал.. а тогда, а сейчас ставил на обновлённую..

@ ukr_unix_user, @ router, @ leave: забавно, но помогает service iptables restart

на данным момент так:

[admin@kvm ~]$ sudo ipcs -s|grep apache 0x00000000 65538 apache 600 1

как завистнет, сделаю ещё.

1) искать причину подземных стуков сложно. Какую систему мониторинга используешь? Включи мониторинг всех возможных параметров. Ну там число сокетов, shared memory и т.п. Если на каком-нибудь графике заметишь корреляцию с проблемой, может появятся идеи.

подземные стуки - по другому и не назовёшь.

сейчас ничего не мониторю кроме трафика. но в прошлый раз мониторил все меняющиеся параметры из sysctl -A (их довольно немного оказалось), корреляции заметить не удалось

посоветуешь чем монитрить чтоб «поставил и работало»? может попробую..

2) При перезапуске apache ты проверяешь что он на самом деле завершился и перестал слушать порт? Может скрипт не отрабатывает

не проверял, проверю.

3) попробую.

4) не, очень врядли, ибо в прошлый раз сразу как переехал из виртуалки явление исчезло как и не бывало. домены в прошлый раз и в этот совсем разные, клиенты разные. только конфигурация одна и та же.. да я.. так что дело в конфигурации/руках. logwatch обычно стоит, сейчас ещё просто не поставил.

а ты делал вот такую штуку?

iptables -I FORWARD -m physdev --physdev-is-bridged -j ACCEPT

или такое добавлял в sysctl.conf?

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

ULOG какой-нибудь? Пройдись по своим правилам, подумай что там могло подвиснуть. В iptables различаются настройки портов nginx'а и apache?

сейчас ничего не мониторю кроме трафика. но в прошлый раз мониторил все меняющиеся параметры из sysctl -A (их довольно немного оказалось), корреляции заметить не удалось

я имел в виду метрики производительности, а не конфигурации. Вряд ли параметры из sysctl будут сами меняться.

посоветуешь чем монитрить чтоб «поставил и работало»? может попробую..

Вряд ли. Своей текущей системой мониторинга не вполне доволен и новые графики к ней прикручиваются через одно место.

зависло

sudo ipcs -s | grep apache

0x00000000 65538 apache 600 1

как видно, ничего не изменилось.

в сисктл предложенные тобой строчки стоят по умолчанию. правда

sysctl -p ругается на них вот так:

error: «net.bridge.bridge-nf-call-ip6tables» is an unknown key error: «net.bridge.bridge-nf-call-iptables» is an unknown key error: «net.bridge.bridge-nf-call-arptables» is an unknown key

что как бы намекает что оно их не понимает... кстати, я так понимаю это нужно на хосте на не внутри виртуальной машины?

попробовал добавить правило в iptables хоста, поглядим.

на хосте на не внутри виртуальной машины?
physdev-is-bridged

phys как бы намекает.

проверил, апач рестартует. сделал ему stop и поглядел ps-ом, его нет. затем запустил. ответ от wget 127.0.0.1

# wget 127.0.0.1
--2012-05-23 10:05:03--  http://127.0.0.1/
Устанавливается соединение с 127.0.0.1:80... сбой: В соединении отказано.

это не ответ апача. и не ответ nginx. остаётся iptables.

nginx весит на внешке и слушает 80 порт. а апач весит на 127.0.0.1 и тоже слушает 80 порт, кстати, перевесить апач на другой порт не удалось потому что selinux ругается. возиться не стал.

правила у меня такие

*filter
:INPUT DROP
:FORWARD DROP
:OUTPUT DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
#-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -m connlimit --connlimit-above 15 --connlimit-mask 32 -j REJECT --reject-with icmp-port-unreachable 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -s 192.168.122.0/24 -j ACCEPT 
#-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT 
-A INPUT -j LOG --log-prefix "dropped input connection: "

-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A OUTPUT -d 192.168.122.0/24 -j ACCEPT 
-A OUTPUT -d 8.8.8.8 -j ACCEPT 
-A OUTPUT -d 8.8.4.4 -j ACCEPT 
-A OUTPUT -d centos.mirrorcatalogs.com -j ACCEPT
-A OUTPUT -o lo -j ACCEPT 
-A OUTPUT -p tcp -m tcp --dport 25 -m state --state NEW -j ACCEPT 
-A OUTPUT -j LOG --log-prefix "dropped outgoing connection: " 

сейчас закоментировал connection-limit и добавил логирование дропнутых инпутов, буду глядеть. спасибо.

да, как бы намекает.

но меня смущает что я перезагружаю iptables *внутри* виртуалки и всё начинает работать. внешнюю машину вообще не трогаю.

is an unknown key error

man sysctl
...
-e     Use this option to ignore errors about unknown keys.
...

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

ну там ведь в сисктл есть ограничения (вроде -min, -max), а есть текущие значения. это как раз и есть метрики производительности, всякие там сокеты, открытые файлы и т.п.

не уловил мысль про «nginx весит на внешке и слушает 80 порт. а апач весит на 127.0.0.1 и тоже слушает 80 порт» это зачем так?

#-A INPUT -p tcp -m tcp --dport 80 -m state --state NEW -m connlimit --connlimit-above 15 --connlimit-mask 32 -j REJECT --reject-with icmp-port-unreachable

Ты дропал в т.ч. обращение к бекенду :) Укажи интерфейс, проблема исчезнет

гм. попробовал, поглядим.

гм-гм, практически, ты прав, что это я не заметил..

но теоретически, в прошлый раз у меня не было nginx как фронтэнд (то есть апач висел на внешнем интерфейсе и слушал сам). а проблема была.

но практически ты можешь оказаться абсолютно прав, буду надеятся :)

nginx отдаёт статику и освобождает апач от медленных клиентов. экономим память..

ну там ведь в сисктл есть ограничения (вроде -min, -max), а есть текущие значения. это как раз и есть метрики производительности, всякие там сокеты, открытые файлы и т.п.

Можно пример?

но теоретически, в прошлый раз у меня не было nginx как фронтэнд (то есть апач висел на внешнем интерфейсе и слушал сам).

Какой-нибудь демон, к которому обращался apache, например fcgid ? Или особенности архитектуры апача.

fs.file-nr

The three values in /proc/sys/fs/file-nr denotes the number of allocated file handles, the number of allocated but unused file handles, and the maximum number of file handles. You can monitor this to keep a check on the file handles.

Спасибо, не знал. Всегда думал что в sysctl только параметры для настройки

Какой-нибудь демон, к которому обращался apache, например fcgid ?

точно нет.

Или особенности архитектуры апача.

не знаю что и думать, если сейчас всё будет работать, придётся думать либо на limitconn который начинает странно работать в витруалке, либо на апач..

Неделя прошла. Давай рассказывай :)

о, а я и не заметил :)

значит так, для начала попробовал указать интерфейс в правиле. время встречи с неведомым увеличилось в разы (а может быть на порядок). но оно всё таки встретилось. убрал правило с конлимитом совсем, пока больше проблему не встречал.

за совет спасибо ещё раз :)

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