On 03/20/2011 06:22 PM, Kevin.Buckley_at_[hidden] wrote:
>> It's not hard to test whether or not SELinux is the problem. You can
>> turn SELinux off on the command-line with this command:
>> setenforce 0
>> Of course, you need to be root in order to do this.
>> After turning SELinux off, you can try reproducing the error. If it
>> still occurs, it's SELinux, if it doesn't the problem is elswhere. When
>> your done, you can reenable SELinux with
>> setenforce 1
>> If you're running your job across multiple nodes, you should disable
>> SELinux on all of them for testing.
> You are not actually disabling SELinux with setenforce 0, just
> putting it into "permissive" mode: SELinux is still active.
That's correct. Thanks for catching my inaccurate choice of words.
> Running SELinux in its permissive mode, as opposed to disabling it
> at boot time, sees SELinux making a log of things that would cause
> it to dive in, were it running in "enforcing" mode.
I forgot about that. Checking those logs will make debugging even easier
for the original poster.
> There's then a tool you can run over that log that will suggest
> the ACL changes you need to make to fix the issue from an SELinux