Re: AH00273: apr_proc_mutex_lock failed, possibly caused by cron, systemd or su

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Rainer Canavan <rainer.canavan <at> sevenval.com> writes:

> we've got an obscure problem with the apache httpd that was shipped
> with CentOS 7.2. We perform automatic builds and updates via cron,
> and, since the update to CentOS 7.2. The update script is triggered by
> cron and stops, yum updates and starts the httpd. When the next cron
> job that is run as the same user as the httpd (not the update job)
> terminates, the httpd frequently fails, starting with a AH00273:
> apr_proc_mutex_lock failed message, and then a never ending loop of
> AH00272 messages, one from each httpd process that is forked, until
> the listener process is stopped.
 
> Does anyone have any ideas what may cause these mutex errors?

Sorry - no ideas, but I'm having the exact same issue, and have been trying
for the better part of a week to figure out what is causing this.

My symptoms are identical, albeit with a slightly different execution path.
 I'm running the packaged and OS-provided httpd, but executed as an
alternate service account with a provided configuration directory (httpd -d
/opt/app/myApp/httpd).  This works for at least days on-end without issue. 
I then added a logrotate cron job, executing as the same user, with a
postrotate command to run "/usr/sbin/httpd -d /opt/app/myApp/httpd -k
graceful".  Once executed through cron, I see exactly the same issue that
you are.  If I execute directly in a bash shell of the service account
without cron, I can repeatedly execute without any concerns.

I tried a compile-from-source HTTPD (2.4.18), suspecting something amiss
with the CentOS-provided HTTPD - but still experienced the exact same issue.

So cron appears to be a common factor here.  My only work-around so far has
been to disable the logrotate cron job.

I've run multiple instances of similar configurations previously without
issue, and am not exactly sure what has changed to cause this in my new
builds.  I am curious if this is new to CentOS 7.2, or possibly 7.1.

I had suspected SELinux.  I tried setting the SELINUX=permissive in
/etc/sysconfig/selinux and rebooting, but still experienced the same issue.

I created a 2nd CentOS VM, installed and configured identically - and as of
yet, have been unsuccessful in re-creating the issue there.  The only
outstanding significant difference I can think of (outside of the server and
user names used) is that it is largely a default HTTP configuration - where
the problem instance has SSL and a minimal ProxyPass configuration running.
 I guess I'll try to clone these configurations over next to see if they
make any difference.

For completeness (from the VM where I am experiencing the issue):

$ cat /etc/centos-release
CentOS Linux release 7.2.1511 (Core)

$ uname -srvmpio
Linux 3.10.0-327.3.1.el7.x86_64 #1 SMP Wed Dec 9 14:09:15 UTC 2015 x86_64
x86_64 x86_64 GNU/Linux



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx




[Index of Archives]     [Open SSH Users]     [Linux ACPI]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Squid]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux