apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: apr_proc_create {detached} pipes?
Date Sun, 15 Apr 2012 21:02:55 GMT
On 4/15/2012 12:41 PM, William A. Rowe Jr. wrote:
> 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?

Stefan I don't see where you detach... did you simply mean that cmd3 was
meant to use detached processes?  As in, not of this process group?

We might be talking of two different bugs.  You are describing where we make
some default pipes and then overwrite with the user's fd's, discarding the
default, autocreated pipes.  I actually thought that enjoyed some cleanup
at 1.3.0 but am not sure how far we got (I mostly focused on windows).

I'm describing where any of these pipes created with any of these mechanics
will be shuttered and replaced by /dev/null fd's upon proc_create where you
have invoked apr_procattr_detach_set(), as it calls apr_proc_detach(), which
flushes away all the stdio channels.

I came across this trying to work around the stupidly implemented SIGTERM
broadcast to prefork's process group (no other MPM is this foolish).  I'm
thinking of a hack of doing a cleanup-for-exec which is actually the
detach, but without the other evil side effects of apr_proc_detach().
Or, that cleanup-for-exec might be able to twist the SIGTERM handler
between fork and exec.

Mime
View raw message