On 4/15/2012 3:50 AM, Stefan Sperling wrote: > On Thu, Apr 12, 2012 at 10:37:13PM -0500, William A. Rowe Jr. wrote: >> Has anyone else ever encountered an opportunity to detach a process, >> which you would still enjoy stdio channels to communicate? > > Yes, this is done in Subversion to run hook scripts. > See svn_io_start_cmd3() in: > https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/io.c > >> First I actually have bumped into this, but we didn't seem to leave >> much in the way of an apr_proc_detach that avoids shuttering stdio >> handles that were *just configured* through the procattr. Seems >> sort of strange to me, because the docs don't make this clear. > > Not sure if this is related but the above mentioned function > contains this comment: > > ### Unfortunately each of these apr functions creates a pipe and then > overwrites the pipe file descriptor with the descriptor we pass > in. The pipes can then never be closed. This is an APR bug. */
I'll give this some further thought and offer up a fix. It seems like we should have honored the user's choice of apr_procattr_file_pipe magic. For simplicity we can make sure in APR 2 that we have three default tags for each stream, a choice between parent's handle, a /dev/null handle and a truly closed/unused fd, alongside the usual pipe and file options. I don't know what the group believes we can change in APR 1.5 since there are all sorts of behavioral implications. But if users were using the apr_procattr options already, no harm, no foul? Have apr_procattr with absolutely no extra file/pipe calls simply mock up the /dev/null setup? Another question came up. What about reducing signals upon apr_proc_create? Would it be helpful to be able to pass 'nohup' style choices to that new process?
