Como resolver o Apache-2.4 AH02026: Falha ao adquirir o bloqueio de cache de sessão SSL

1

Acabei de levantar um novo servidor AWS Ubuntu 16.04 executando o Apache2.4 com o PHP-FPM 5.6 e 7.1 disponível através de sockets diferentes. Tudo está funcionando muito bem, mas estou recebendo os seguintes erros no log de erros do Apache:

[Mon Jun 19 05:48:06.158306 2017] [ssl:warn] [pid 18652:tid 140274127963904] (35)Resource deadlock avoided: AH02026: Failed to acquire SSL session cache lock

Agora, eu não sou guru de servidores, é por isso que estou aqui. Eu estou pensando que pode ser permissões no diretório ssl socket cache, mas isso está fora da minha zona de conforto, então eu preciso de algum aconselhamento especializado / orientação.

cd ing para o diretório Apache e grep ing o termo APACHE_RUN_DIR fornece o seguinte:

foo@bar:/etc/apache2# grep -R "APACHE_RUN_DIR" ./
./mods-available/cgid.conf:ScriptSock ${APACHE_RUN_DIR}/cgisock
./mods-available/ssl.conf:      #SSLSessionCache                 dbm:${APACHE_RUN_DIR}/ssl_scache
./mods-available/ssl.conf:      SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
./mods-enabled/ssl.conf:        #SSLSessionCache                 dbm:${APACHE_RUN_DIR}/ssl_scache
./mods-enabled/ssl.conf:        SSLSessionCache         shmcb:${APACHE_RUN_DIR}/ssl_scache(512000)
./envvars:export APACHE_RUN_DIR=/var/run/apache2$SUFFIX

Assim, podemos ver que não apenas o mod_ssl está disponível e ativado, mas também o runnign com uma configuração que declara que o SSLSessionCache está localizado em ${APACHE_RUN_DIR}/ssl_scache , o que equivale a /var/run/apache2/ssl_scache .

Eu notei que o diretório não existia, então criei com cd /var/run/apache2 seguido por mkdir ssl_scache . Executar um ls nos diretórios fornece o seguinte:

foo@bar:/etc/apache2# ls -lsa /var/run/apache2/
total 4
0 drwxr-xr-x  3 root root   80 Jun 19 15:34 .
0 drwxr-xr-x 25 root root 1060 Jun 19 14:44 ..
4 -rw-r--r--  1 root root    6 Jun 19 15:46 apache2.pid
0 drwxr-xr-x  2 root root   40 Jun 19 15:34 ssl_scache
foo@bar:/etc/apache2# ls -lsa /var/run/apache2/ssl_scache/
total 0
0 drwxr-xr-x 2 root root 40 Jun 19 15:34 .
0 drwxr-xr-x 3 root root 80 Jun 19 15:34 ..

Além disso, temos isso quando usamos ps aux procurando por apache:

foo@bar:/etc/apache2# ps aux | grep "apache"
root     16506  0.0  0.1 109328  9104 ?        Ss   Jun18   0:03 /usr/sbin/apache2 -k start
root     17387  0.0  0.0  22780  4808 pts/0    T    15:22   0:00 nano apache.error.log
www-data 18652  0.4  0.3 2044052 23388 ?       Sl   15:46   0:04 /usr/sbin/apache2 -k start
www-data 18720  0.4  0.3 2044728 24104 ?       Sl   15:48   0:03 /usr/sbin/apache2 -k start
www-data 18839  0.4  0.2 2043272 22480 ?       Sl   15:50   0:02 /usr/sbin/apache2 -k start
root     18913  0.0  0.0  12944   964 pts/0    S+   16:01   0:00 grep --color=auto apache

Assim, posso ver que o processo do Apache está sendo executado como usuário www-data . Eu estou supondo que talvez não possa acessar o folde /var/run/apache2/ssl_scache ? Mas como eu disse, não sou guru.

Alguém é capaz de esclarecer por que eu continuo recebendo AH02026 de erros?

    
por e_i_pi 19.06.2017 / 08:04

1 resposta

0

Então, encontrei a causa raiz do problema e a solução. Acontece que há um bug no Apache2.4 no Ubuntu 14.04 e 16.04 (veja link ).

Por padrão, esta linha no arquivo /etc/apache2/apache.conf não está comentada:

Mutex file:${APACHE_LOCK_DIR} default

Por direito, esta diretiva de configuração deve fazer com que o arquivo mutex use o mecanismo padrão. Se, em uma instalação baunilha do Apache2, você executar o seguinte comando no prompt de comando:

apache2ctl -t -D DUMP_RUN_CFG

... deve dar a seguinte saída:

Mutex default: dir="/var/lock/apache2" mechanism=default

Em vez disso, devido ao erro, isso produz:

Mutex default: dir="/var/lock/apache2" mechanism=fcntl

Existem duas correções possíveis:

  1. A solução mais longa é usar o mecanismo fcntl em vez do mecanismo padrão, que incluiria a criação de arquivos mutex, dando-lhes permissões, configurando soquetes, monitorando-os e um monte de problemas que não entro aqui (principalmente porque está acima do meu salário)
  2. A solução fácil é comentar a linha mutex em /etc/apache2/apache.conf , assim:

    #Mutex file:${APACHE_LOCK_DIR} default

... que resulta no mecanismo padrão usado pelo Apache.

    
por 29.06.2017 / 02:41