2

Я использую сервер с использованием Apache, и журнал ошибок Apache периодически получает это предупреждение, обычно при посещении сайта, и обычно в группах по крайней мере два или три одновременно.

[Sun Nov 22 15:23:59.570652 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80

pid 4542 является родительским процессом для apache. Мне любопытно, что вызывает эти предупреждения, указывают ли они на проблему, и что я могу сделать, чтобы они не заполняли журнал ошибок apache.

Я уже провел некоторое тестирование и исследование, и у меня есть некоторые идеи о том, что может происходить. Самым полезным на данный момент было включение ведения журнала trace8 для apache, которое показало, что после каждого предупреждения «(111) Отказ в соединении» следовало закрытие дочернего процесса apache. Когда есть группа предупреждений, за первым или двумя сразу же последует закрытие дочернего процесса apache, а затем последующее предупреждение будет иметь задержку до 12 секунд до закрытия дочернего процесса. И затем в течение минуты после закрытия последнего процесса откроются новые, чтобы заполнить освободившиеся слоты. Вот лог выдержка одного раунда всего процесса:

[Sun Nov 22 15:23:59.570652 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80
[Sun Nov 22 15:24:01.570677 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80
[Sun Nov 22 15:24:01.570721 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5760 (gen 2/slot 11) exited 
[Sun Nov 22 15:24:03.570674 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80
[Sun Nov 22 15:24:05.570674 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80
[Sun Nov 22 15:24:05.570712 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5762 (gen 2/slot 12) exited
[Sun Nov 22 15:24:07.570703 2015] [core:warn] [pid 4542] (111)Connection refused: AH00056: connect to listener on [::]:80
[Sun Nov 22 15:24:13.576458 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5701 (gen 2/slot 1) exited
[Sun Nov 22 15:24:14.577507 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5703 (gen 2/slot 7) exited
[Sun Nov 22 15:24:17.580632 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5712 (gen 2/slot 6) exited
[Sun Nov 22 15:24:46.608431 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5800 (gen 2/slot 1) started
[Sun Nov 22 15:24:49.611368 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5802 (gen 2/slot 6) started
[Sun Nov 22 15:26:16.699374 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5851 (gen 2/slot 7) started
[Sun Nov 22 15:26:17.701274 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5852 (gen 2/slot 11) started
[Sun Nov 22 15:26:17.701821 2015] [core:trace4] [pid 4542] mpm_common.c(534): mpm child 5853 (gen 2/slot 12) started

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

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

/etc/apache2$ sudo iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
bitmask    all  --  anywhere             anywhere            

Chain bitmask (1 references)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.1.0/24      
ACCEPT     udp  --  192.168.1.0/24       anywhere             udp dpt:domain
ACCEPT     tcp  --  192.168.1.0/24       anywhere             tcp dpt:domain
RETURN     udp  --  anywhere             239.255.255.250      udp dpt:1900
RETURN     udp  --  anywhere             224.0.0.251          udp dpt:mdns
ACCEPT     all  --  anywhere             anon.riseup.net     
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Любые объяснения для понимания и / или остановки этого предупреждения журнала приветствуются. Или дальнейшие испытания в этом направлении. Спасибо.

0