<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sun, Aug 30, 2015 at 9:19 AM Alexander Kjeldaas <<a href="mailto:alexander.kjeldaas@gmail.com">alexander.kjeldaas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The directory is irrelevant.  fork() + exec() is not an atomic operation:</div></blockquote><div><br></div><div>This creates problems for all resources that act as locks. IIRC (it's been a few years since I looked through it thoroughly), it's been shown that there isn't a general fix for this. I.e - that the POSIX threading model & fork()  will having timing issues of some sort or another no matter what you do. The work-around is to only fork when no such resources are held. So you do things like fork all your processes before starting a thread, or fork a server that will do all further forks upon request before starting a thread, etc.</div><div><br></div><div>So the question should not be whether CLO_EXEC "fixes everything", but whether having it as the default is a good enough idea to be worth the pain of changing. I suspect the answer is yes, as most cases where it isn't set are probably because it's the default, so won't need changing.</div></div></div>