>I understand why functions like closefds() are used right before exec(), >but in this case a fair amonut of stuff happens before exec is called, >and it's way before fork() is eventually called as well. The other uses >of closefds() are after a fork() occurs, or right before exec() happens >(see whom.c). Can anyone think of a reason that for this specific >case closefds() should NOT be moved from whatnowbr.c (and send.c) into >sendsbr.c, and just in the child process?
So, following up to myself .... At least I figured out why closefds() is calld so early. The issue is the use of the -idanno flag. This flag is used to pass a file descriptor down for annotations (the called of "post" passes down a file descriptor number using -idanno, and post writes out the annotation to that descriptor). So we'd need to either call closefds() before the annotations descriptor is created, or make it so closefds() can skip one particular descriptor. But the bigger question is ... why is closefds() used at all? I see it being used by rcvtty(1), repl(1), send(1), slocal(1), whatnow(1), and whom(1), 6 instances at all. But by my count there are 28 calls to exec*(); I didn't match them all up, but it seems like most of the time we start a child process we don't bother closing all descriptors. I realize this was a common practice "back in the day", but if any library functions create a descriptor they should use O_CLOEXEC or FD_CLOEXEC. And if the concern is nmh leaking file descriptors, we should either fix that problem or use FD_CLOEXEC ourselves. This isn't just an nmh problem either ... I see a similar inconsistent use of closefds() in the MH source code. I suggest we simply remove closefds() completely. Ralph, David, I saw your comments ... with my follow-up information, what do you think of that? --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
