[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Applying alias file , to Reply-To: and From: component

From: Ken Hornstein
Subject: Re: [Nmh-workers] Applying alias file , to Reply-To: and From: components of a draft
Date: Tue, 11 Nov 2014 22:25:44 -0500

>That's fine, but wasn't my first attempt.
>    $ whom <(echo To: me)
>    whom: unable to open /dev/fd/63: No such file or directory
>    $

I'm unclear on what should really be happening here, as I'm not familiar
with that syntax.

Okay, I just read up on it.  Huh, didn't know about that.

>whom forks and close(2)s file descriptors [3, 255] along the way,
>trampling 63.  Is this `close all the file descriptors' approach still
>needed with more modern facilities like O_CLOEXEC?  Can nmh just take
>care to ensure file descriptors it opens that shouldn't cross execve(2)
>are marked to be closed on exec?  It shouldn't bother itself with all
>file descriptors?

... yeah, I have to agree with you there.  I think by now all library
calls that create file descriptors should be setting the close-on-exec
flag, right?  That's been around forever.  Although I'm not sure
O_CLOEXEC has been around forever, has it?  I know the fcntl()
equivalent has.  We should go through and audit all open() calls and set
the FD_CLOEXEC flag where appropriate.

>(Is 255 fixed?  File descriptors can run far higher on some systems, and
>closing them all can take time, e.g. Apache used to suffer from this.
>The BSDs added http://manned.org/closefrom.2 to lessen the calls, but it
>still tramples willy-nilly.)

It looks like it's based on OPEN_MAX ... which is kind of bogus.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]