I have applied fix provided here:
/http://undefinederror.org/modsecurity-audit-log-failed-to-unlock-global-mutex-permission-denied/
Seems to work.
/http://undefinederror.org/modsecurity-audit-log-failed-to-unlock-global-mutex-permission-denied/
Seems to work.
We are working to resolve the incompatibilities between mod_security and mod_ruid2. We hope to have these resolved in EasyApache 3.24
Please open a separate thread to address issues not specifically related to Mod_Ruid2 and Mod_Security. Ensure you provide specific details about what's not working properly.
Thank you.
I was hoping this too :D but I don't see it mentioned in the changelog for 3.24 unfortunately... for me fixing this bug is high on my priority list so maybe in the next version of EasyApache?...
I have a new server build with Easy::Apache v3.24.11 on
CENTOS 6.5 x86_64 standard – rs11
WHM 11.40.1 (build 11)
Apache 2.4 with Ruid2 and mod_security
Just discovered that mod_security is still throwing these errors:
Audit log: Failed to lock global mutex: Permission denied
Is this a show stopper? Do I need to rebuild and remove mod_security?
The compatibility issues between Mod Ruid2 and Mod Security were resolved as of EasyApache version 3.24.12, which was released on March 10th, 2014.
running latest easyapache as of now and still getting Failed to lock global mutex: Permission denied in the logs
I got this same issue after moving from SuPHP o FastCGI. To sort that out I think I ran upcp --force - it's been awhile but it solved the issue. We however moved back to suPHP due to a different error. Really considering trying out mod ruid2 now.
I continued to have this same issue after the update but upcp --force fixed it as mentioned above.
But I'm confused because of this mod_ruid2 fix.
The modsec_audit log has stopped being updated in the ConfigServer ModSecurity Control (cmc)
The modsec_audit log entries have changed drastically and are not the same as before
The new modsecurity logging directories when using mod_ruid2 makes me sick.
But I'm confused because of this mod_ruid2 fix.
The modsec_audit log has stopped being updated in the ConfigServer ModSecurity Control (cmc)
The modsec_audit log entries have changed drastically and are not the same as before
The new modsecurity logging directories when using mod_ruid2 makes me sick.
You may want to report the issue to ConfigServer so they can update their application to support the logging changes implemented when Mod_Security and Mod_Ruid2 are enabled. Other than the path difference, is it causing any actual functionality issues?
Thank you.
I will try to report this to ConfigServer.
The entries in the modsec_audit log changed when I ran upcp --force to apply the fix, as they got much less informative and made me a bit confused by the changes. But the logs in the new logging directories do have these entries as before in the same manner so it seems to be working normally.
But these entries are not as easily accessible as the entries in the modsec_audit log where you just have to access the log in /usr/local/apache/logs, while the more informative logs in the new logging directories are on multiple levels by timestamps which I'm not used to when checking logs.
The below image is a tree view of the logs location in /usr/local/apache/logs/modsec_audit/nobody directory.
Last edited:
As I understand, the change to the logging was required to ensure compatibility between Mod_Ruid2 and Mod_Security. That being said, you are welcome to submit a feature request to have this method of logging revisited:
Submit A Feature Request
Thank you.
Submit A Feature Request
Thank you.
I am still seeing this issue with the latest version of cPanel and a rebuilt PHP 5.4.30 and ruid2. I thought this was resolved?
