(Please forgive the cross post, but I felt it relavent to the
httpd group, since it impacts them and module developers such as
myself.)
Please find enclosed a proposed solution for the bug I posted last
month:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056
The source code
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.
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
+1, this looks like very useful function. I would like to see a bit
more explanation in the child_errfn_set making it clear that this
function is used to accurately report failures in the 'exec' of a 'fork
exec'. Also explicitly state that this function can only be used on
systems that use
--On Wednesday, February 5, 2003 9:59 AM -0500 Jeff Trawick
[EMAIL PROTECTED] wrote:
Any concerns, particularly with respect to how the app determines
if the feature is available? I think it would be fine to make the
feature always available but to simply note that on some platforms
the
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
At 08:59 AM 2/5/2003, Jeff Trawick wrote:
Any concerns, particularly with respect to how the app determines if the
feature is available? I think it would be fine to make the feature always
available but to simply note that on some platforms the application-specified
error function would never
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
William A. Rowe, Jr. wrote:
At 08:59 AM 2/5/2003, Jeff Trawick wrote:
Any concerns, particularly with respect to how the app determines if
the feature is available? I think it would be fine to make the
feature always available but to simply note that on some platforms the
application-specified
--On Wednesday, February 5, 2003 12:53 PM -0500 Jeff Trawick
[EMAIL PROTECTED] wrote:
I'd like to see some +1s for this from others. I'm not sure that
it is a bug not to have the function. I'm not really opposed, I
simply would choose to continue adding process attributes rather
than more
I'd like to propose a new function in the apr_filepath module, to be
added for 0.9.2 and/or httpd-2.0.45:
/**
* Split a search path defined in an environment variable (e.g., @c $PATH)
* into separate components
* @ingroup apr_filepath
* @param pathelts the returned components of the search
At 06:14 AM 2/5/2003, Anthony Howe wrote:
Please find enclosed a proposed solution for the bug I posted last month:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056
The source code comments in the patch should explain everything. I'm currently
testing this against Apache 2.0.44 and
William A. Rowe, Jr. wrote:
At 11:53 AM 2/5/2003, Jeff Trawick wrote:
on APR not providing a string which tells what type of processing failed:
With no string from APR, you don't know if, for example, the failure
was EPERM because
a) permissions on working directory were bad
b) permissions on
++1 if we can go with
APR_DECLARE(apr_status_t) apr_filepath_list_split(
apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
APR_DECLARE(apr_status_t) apr_filepath_list_merge(
char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
Let's drop the 'env' concept -
At 02:19 PM 2/5/2003, Jeff Trawick wrote:
William A. Rowe, Jr. wrote:
At 11:53 AM 2/5/2003, Jeff Trawick wrote:
on APR not providing a string which tells what type of processing failed:
With no string from APR, you don't know if, for example, the failure was
EPERM because
a) permissions on
At 09:11 AM 1/31/2003, Bill Stoddard wrote:
As for your question about polling, if we cycle every second we waste
cpu - if we sample every few seconds we lose more log entries etc.
If we receive alerts when the otherchild processes die we can react
immediately without the extra loops.
In
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16056
Anthony, I like the gist of your patch, but your ownership
observations were correct; we can't implement this patch as
written. This was just addressed in recent Apache releases and
will continue to be tightened, not loosened.
Bugger.
But I
William A. Rowe, Jr. wrote:
++1 if we can go with
APR_DECLARE(apr_status_t) apr_filepath_list_split(
apr_array_header_t **pathelts, const char *liststr, apr_pool_t *p);
APR_DECLARE(apr_status_t) apr_filepath_list_merge(
char **liststr, apr_array_header_t *pathelts, apr_pool_t *p);
I
17 matches
Mail list logo
