ModSecurity GeoLookup Proc Mutex Denied
Hello,
My error logs are filling up with "ModSecurity: Geo Lookup: Failed to lock proc mutex: Permission denied", and only this error. No database errors, no 'global mutex', no 'audit log', no 'rule processing failed', no DBM file errors, etc. Each time the error shows up, I get 14 identical errors within milliseconds -- 14 errors for each file that the website is trying to load - mostly image files. For each of these individual errors, an 'audit log' error file and directory is created in a subfolder of /usr/local/apache/logs .
I use ModSecurity Geolookup to block countries from my website that have been attempting brute force or other attacks into my websites. ModSec Tools shows that the rules are processing effectively (IPs from the prohibited countries are being blocked). The Client IPs that are causing these errors are not from the prohibited countries.
WHM 54.0 build 17
Apache 2.4
PHP 5.5
MPM Prefork
Mod Ruid2
DSO
Mod Security 2.9.0
Interestingly, I think these errors began when I upgraded to PHP 5.5 and Apache 2.4 (from php 5.3 and apache 2.2).
I've done some reading on these forums, but many of them relate to 'audit log -- global mutex' errors, and I think that this is different from that.
I'm assuming that ruid2 is probably the issue here, but I've also read that this issue has been corrected in earlier versions of modsecurity.
Has anybody else had these errors -- and fixed them? Is there something I can do to prevent these specific errors (and the audit logs) from being created?
Thanks!
-Patrick
-
Ca you post some sample error logs ? 0 -
I included 'sample error_log.txt' from early this morning. Here, you can see the 14x repeated 'failed to lock proc mutex' errors. At the bottom of the log, you can see that mod_sec successfully blocked some prohibited IPs as per the geo loc rules. However, it is saying that .htaccess is not readable or executable. I also included 'sample modsec_audit.txt' that coincides with this morning's error_log. There are two subfolders in the /usr/local/apache/logs/modsec_audit folder: nobody & username ... they both have these types of files in them (modsec_audit.txt type files.) Also, I have 10 apache processes running right now. 9 of them are run by 'nobody' while 1 of them is run by 'root'. Perhaps that's why I have two modsec_audit subfolders? Yes, this is a wordpress site. Permissions on /public_html 750 Permissions on /public_html/.htaccess 644 ** Once again -- I'm just trying to stop the error_logs from filling up with those 'failed to lock proc mutex' errors. Thanks for your help! 0 -
Hello :) Please see the following thread for more information about the error messages you have reported: Mod RUID 2 and ModSecurity Thank you. 0 -
Thank you for your reply. I read the post and am still a bit confused (sorry!) It looks like the folks at cPanel were close to a fix in 2014 and 2015, but it never materialized (a fix for ruid2 and mod_sec). As for the rest of the thread, it starts talking about DBM errors, and changing permissions on the .DBM files -- I am not having these particular errors. Was there more that I should have understood from that thread -- other than the fact that ruid2 and mod_security just aren't happy together? 0 -
I went back to Apache 2.2 (from 2.4), kept all other settings the same (kept php5.5, Ruid2, DSO, etc.), and no more "Geo Lookup: Failed to lock proc mutex" errors filling up my logs! Strange ... 0 -
I went back to Apache 2.2 (from 2.4), kept all other settings the same (kept php5.5, Ruid2, DSO, etc.), and no more "Geo Lookup: Failed to lock proc mutex" errors filling up my logs! Strange ...
Was there more that I should have understood from that thread -- other than the fact that ruid2 and mod_security just aren't happy together?
It's mostly a design issue with Mod_Security. Under Mod_Ruid2/MPM-ITK, the Apache process is being run as the cPanel user itself, and therefore does not have access to obtain a lock on the GeoIP database. This is not an issue on systems without without Mod_Ruid2/MPM-ITK. Thank you.0
Please sign in to leave a comment.
Comments
6 comments