On 03/20/2011 06:22 PM, kevin.buck...@ecs.vuw.ac.nz 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 > perspective. > -- Prentice
