> Actually, I mis-spoke: it was because of the fork(). C code I write > always does a fflush(NULL) before a fork(), to ensure that content > doesn't get doubled. I think I picked this habit up from a W. Richard > Stevens book (not sure, it's been too many years). It's that, more than > anything about any particular I/O stream. > > Looking briefly at the codepaths, it looks like some logs going to > stderr may be in buffers at the point of the fork. I don't have time to > investigate further at this point.
That's what I was afraid of: It is not known what's open and inherited at a security boundary transition, so everything is flushed. > Seriously, much as I'd be happy to see Sun4 compatibility restored[*], if > ANSI C stdio is to be avoided at this level, we may be in the territory > of "patches needed to build". fflush(NULL) usually says "I got lost and try to cover that by saying I write robust code". There are ways to let this code work unmodified even on SunOS 4, like macros using wrapper functions, but to me it looks like a particularly bad place to get lost. As for logging, I see log_close_all() and prefer to see something like log_flush_all() being called, so it is easy to know what's going on there. I would have expected exim_exit() to be used in the child and having that call log_close_all(), instead fflush(NULL) and _exit() is used. If that is to avoid the side effects of exim_exit(), the child should rather free resources that must not be used first. Given all that, I'm far from suggesting to change anything there without understanding it really. :-/ Michael -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
