Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process

[Greg Ames <gr...@apache.org>]

Jeff Trawick wrote:
> On Unix, some failures of apr_proc_create() are not noticed in the 
> calling process and so apr_proc_create() returns APR_SUCCESS even though 
> it failed.

++1 in concept.  It has bugged me for a long time that httpd 2.0 only logs 
"Premature end of script headers" no matter what is wrong with a CGI.  ISTR that 
1.3 provided better diagnostic info, perhaps at the cost of more overhead.

> Some of the potential failures could be discovered in the parent by 
> using extra syscalls (e.g., use stat to make sure the program actually 
> exists and can be executed by this user, use stat to make sure the 
> desired working directory actually exists and can be chdir-ed to by this 
> user).  It isn't appropriate to burn the required cycles by default, but 
> it would be nice to allow the app to turn on this extra checking, since 
> failures of apr_proc_create() can be handled much cleaner if the 
> function returns an error status.
> 
> Alternatively, APR could allow the application to get called in the 
> child process in the failure cases and allow it to do whatever is 
> appropriate (log a message, synchronize with the parent process, etc.).

Couldn't the stat's, chdir's, etc. be done only after a failure to keep the 
overhead out of the mainline path?  Then each app wouldn't have to rewrite the 
basic diagnostic code.

Having an optional callback in the app do the logging is a good idea.  It gets 
around the problem of the library spewing messages to stderr which the app may 
not want.

Greg

Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process

[Jeff Trawick <tr...@attglobal.net>]

Greg Ames wrote:

> > Alternatively, APR could allow the application to get called in the
> > child process in the failure cases and allow it to do whatever is
> > appropriate (log a message, synchronize with the parent process, etc.).
>
>
> Couldn't the stat's, chdir's, etc. be done only after a failure to keep
> the overhead out of the mainline path?  Then each app wouldn't have to
> rewrite the basic diagnostic code.


After a failure of exec() or chdir() we already know the reason of the 
error, so such extra checking in the error path is not helpful.  The 
problem with waiting until after something fails in the child is that 
there is no straightforward way for APR to communicate the specific 
reason for failure to the parent.  The parent (the app that calls 
apr_proc_create()) is long gone from its call to apr_proc_create().  All 
that happens is that the child exits with code -1, and the parent can 
find out by calling apr_proc_wait().

A particular application may have a suitable way to communicate this 
info to the parent in its own code, and APR will make that info 
available to the application via the child error function.

Re: [PATCH] letting the app do something useful when apr_proc_create() fails in the child process

[Jeff Trawick <tr...@attglobal.net>]

Greg Ames wrote:

> > Alternatively, APR could allow the application to get called in the
> > child process in the failure cases and allow it to do whatever is
> > appropriate (log a message, synchronize with the parent process, etc.).
>
>
> Couldn't the stat's, chdir's, etc. be done only after a failure to keep
> the overhead out of the mainline path?  Then each app wouldn't have to
> rewrite the basic diagnostic code.


After a failure of exec() or chdir() we already know the reason of the 
error, so such extra checking in the error path is not helpful.  The 
problem with waiting until after something fails in the child is that 
there is no straightforward way for APR to communicate the specific 
reason for failure to the parent.  The parent (the app that calls 
apr_proc_create()) is long gone from its call to apr_proc_create().  All 
that happens is that the child exits with code -1, and the parent can 
find out by calling apr_proc_wait().

A particular application may have a suitable way to communicate this 
info to the parent in its own code, and APR will make that info 
available to the application via the child error function.