1

I've just stood up a new AWS Ubuntu 16.04 server running Apache2.4 with PHP-FPM 5.6 and 7.1 available via different sockets. Everything is working great, but I'm getting the following errors in the Apache error log:

[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

Now, I'm no server guru, that's why I'm here. I'm thinking it might be permissions on the ssl socket cache directory, but this is out of my comfort zone, so I need some expert advice / guidance.

cding to the Apache directory and greping the term APACHE_RUN_DIR gives the following:

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

So, we can see not only is mod_ssl available and enabled, it is also runnign with a configuration that states the SSLSessionCache is located at ${APACHE_RUN_DIR}/ssl_scache, which equates to /var/run/apache2/ssl_scache.

I noticed that directory didn't exist, so I created it with cd /var/run/apache2 followed by mkdir ssl_scache. Running a ls on the directories gives the following:

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 ..

Also, we have this when using ps aux looking for 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

So I can see that the Apache process is running as user www-data. I'm guessing maybe it can't access the folde /var/run/apache2/ssl_scache? But as I said, I'm no guru.

Is anyone able to shed some insight into why I keep getting AH02026 errors?

0

So I've found the root cause of the problem, and the solution. It turns out that there's a bug in Apache2.4 on Ubuntu 14.04 and 16.04 (see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1565744).

By default this line in the file /etc/apache2/apache.conf is uncommented:

Mutex file:${APACHE_LOCK_DIR} default

By rights, this configuration directive should cause the mutex file to use the default mechanism. If, in a vanilla installation of Apache2 you run the following command from the command prompt:

apache2ctl -t -D DUMP_RUN_CFG

...it should give the following output:

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

Instead, due to the bug, it produces this:

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

There are two possible fixes:

  1. The long fix is to use the fcntl mechanism instead of the default mechanism, which would include creating mutex files, giving them permissions, setting up sockets, monitoring them, and a whole heap of pain which I won't go into here (mostly because it's above my pay grade)
  2. The easy fix is to comment out the mutex line in /etc/apache2/apache.conf, like so:

    #Mutex file:${APACHE_LOCK_DIR} default

...which then results in the default mechanism being used by Apache.

  • Already commented this line in apache.conf. But not working. – Dhaduk Mitesh Mar 8 at 5:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.