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