collection_retrieve_ex: Failed to lock proc mutex

[davewichers]

The use of mutex's was introduced in v2.9.2 to address issue: #1224. I'm now seeing this error in my ModSecurity audit logs:

Message: collection_retrieve_ex: Failed to lock proc mutex: Identifier removed
Message: collection_retrieve_ex: Failed to lock proc mutex: Identifier removed
Message: Audit log: Failed to lock global mutex: Identifier removed

Was a bug introduced?? I'm using ModSec 2.9.2 with OWASP CRS 3.0.2 on CentOS 7 wth Apache 2.4.6-67

[victorhora]

@davewichers

The mutex introduced in 2.9.2 is optional: 112ba45

So unless you build it specifically with the --enable-collection-global-lock during the ./configure phase the feature will be disabled.

If you are experiencing issues with collections, It might be a good idea to enable it (See #576 (comment))

[davewichers]

I have no idea if I'm using collections or not. I'm just deploying mod_sec. I also didn't build modsec 2.9.2 as I'm pulling down the version that is available for CentOS7 from yum. So I don't know if it is enabled or disabled by default in the version I'm using. How do I enable it to see if it makes this issue go away?? And enable via configuration, not via compilation, as I'm not compiling what I'm using.

[victorhora]

@davewichers

If you are using the OWASP CRS rules, then you are definitely using collections. See Persistent Storage for more information on collections.

If you haven't compiled the package yourself, I'm not sure if there's an easy way to find out if you have this enabled or not. Your best bet is probably getting the source RPM or spec file from the package and looking into how it was configured/compiled (see #1779 (comment))) as suggested on the other issue.

[davewichers]

Your last paragraph above emphasizes the point I made in #1913. That this is hard to figure out. If it was compiled in by default, and simply enabled disabled with a runtime configuration file, rather than a compile time configuration file, a user could simply look for the current setting, and switch it if they want to change the behavior. And they would never have to figure out if the feature is included or not, as it would always be included, but maybe off by default.

[victorhora]

@davewichers

Please bear in mind that some configuration options are simply unfeasible to be configured at runtime. Either because it could affect performance or it could make the engine more fragile or would require too many changes and developers time (when pending bugs/features with higher priority needs to be worked on).

Note that although we take user-friendliness into account with new features/improvements/fixes, ModSecurity core is not meant to excel in user-friendliness, but rather a performance focused, general purpose, highly customizable WAF engine (not a "WAF product") hence why most WAF products uses ModSecurity WAF as the backend engine.

WAF product vendors take the ModSecurity WAF engine code, tune it to their needs and add user friendly interfaces and users don't need to worry about specific features or patches being enabled/applied as usually the vendors takes care of all of that.

If you are struggling with features being disabled on a specific packaged version of ModSecurity by a third party (e.g. CentOS) I would suggest taking these concerns to the packagers or using a WAF product that takes care of all of that for you.

[dmschlot]

Sorry but I'm unclear how to resolve this. I too am using Centos 7 and installed mod_security using yum. I can compile it if needed but unclear if that is needed or what. What needs to be done to resolve these errors?

Message: collection_retrieve_ex: Failed to lock proc mutex: Identifier removed
Message: Audit log: Failed to lock global mutex: Identifier removed

Thanks,
David