Re: [nmh-workers] closefds() _before_ fork?

[Andy Bradford]

Thus said Ken Hornstein on Tue, 23 Apr 2019 19:35:11 -0400:

> >setlock /tmp/mit.lock inc +MyIncTmp ...
> 
> Well, my reading of the setlock man page (assuming this is the FreeBSD
> one) is that it  is not depending on a _descriptor_  to be passed down
> (I don't even know  how that would work), but in fact  it is opening a
> particular _file_ and locking it.

Sorry,  I should  have referenced  which  setlock I  intended. I  didn't
realize there  was more  than one  setlock. I  specifically had  in mind
setlock from daemontools  (see http://cr.yp.to/daemontools.html for more
information), though  it is  not the only  command that  implements this
interface.

Basically, it opens a file and  attempts to obtain an exclusive lock the
file  descriptor for  that  file. If/when  it  successfully obtains  the
exclusive lock  it then uses exec()  to execute a new  process, and that
new process inherits  the open file descriptor. As long  as that process
leaves the file  descriptor open, it continues to hold  the lock on said
file  which  prevents  any  similarly  invoked  processes  from  running
concurrently.

The  lock goes  away either  when the  file descriptor  is intentionally
closed, or the process exits or crashes.


> My change makes it so we no longer close all descriptors when creating
> a child process (in the majority of cases we didn't).  The particular
> change I have started implementing is that any descriptors _created by
> nmh_ will be marked as close-on-exec, so they will no longer be available
> to child processes (well, technically, child processes that have called
> exec(), but you know what I mean).

Yes, I see  what you mean---also, I didn't realize  that the approach in
nmh was so  varied, but then, I haven't looked  at the sources in-depth.
This change sounds  less drastic than I intially thought.  I've run into
problems before (most notably with Bash) where after setlock does exec()
the  new  process  will  close inherited  open  file  descriptors  which
basically  breaks this  particular  way of  resource control  (sometimes
referred to as Bernstein chaining).

Thanks  for  the  clarification;  it  does sound  like  it  will  be  an
improvement.

Andy
-- 
TAI64 timestamp: 400000005cbfdd37