Many thanks to Ruediger for reviewing 2.0 and 2.2 so far, and to both
Jim and Jeff for their reviews of current/2.2 modern flavors. I could
use a set of eyeballs on the final log.c patch for 2.2, and the patch
set for our old 'n crusty 2.0.
I'm especially interested if any Win32 folks want to take a peek at my
suggested mpm_winnt change set before I commit it to 2.0. Holler if
you are.
There is a patch over at apr-1.x trunk waiting for comments so I can
call 1.2 and 0.9 baked. Essentially, I've given up; Ryan and I had
attempted to make Win32 inheritance behave as Unix fork() inheritance,
and it just made zero sense and the end of the day.
If you study mpm_winnt, we don't even open our listeners and mutexes
as inherited; we start the process (suspended), duplicate the desired
handles into the child process, and then send the child's handle id's
down to it via the stdin channel. Sounds like unix domain sockets, eh?
So the model didn't work, and for NT I propose to stop inheriting the
handles other than stdin/out/err. Leave only the currently dup2()'ed
handle as inherited, and temporarily uninherit even those, when they
have been overridden. Why leave them inherited at all? For good old
classic apps that still rely on classic inheritance.
Since we can't do this in Win9x, there is a trivial patch that makes
the problem of holding open the old error log go away there, too.
--- server/log.c (revision 569931)
+++ server/log.c (working copy)
@@ -265,6 +265,10 @@
apr_proc_t *procnew;
apr_file_t *errfile;
+ if (dummy_stderr)
+ if ((rc = apr_file_open_stderr(&errfile, p)) == APR_SUCCESS)
+ apr_file_inherit_unset(errfile);
+
if (((rc = apr_procattr_create(&procattr, p)) == APR_SUCCESS)
&& ((rc = apr_procattr_cmdtype_set(procattr,
APR_SHELLCMD_ENV)) == APR_SUCCESS)
Essentially, before we play with proc_create, we tell apr that we don't want
stderr ever inherited by any process, ever again. This is a noop on NT, and
just forces stderr to be closed on fork before exec on unix (before, I trust,
stdout replaces the stderr.) So on unix, it's also effectively a no-op.
Something to ponder - I'm really not that motivated to apply this fix just
for Win9x, but if people holler before we tag httpd again, I'll stand behind
the patch. I don't know if it has any impact on the other implementations
of apr_proc_create().
Bill
[EMAIL PROTECTED] wrote:
> Author: wrowe
> Date: Sun Aug 26 18:24:43 2007
> New Revision: 569947
>
> URL: http://svn.apache.org/viewvc?rev=569947&view=rev
> Log:
> Some final suggestions for 2.2.6
>
> Modified:
> httpd/httpd/branches/2.2.x/STATUS
>
> Modified: httpd/httpd/branches/2.2.x/STATUS
> URL:
> http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/STATUS?rev=569947&r1=569946&r2=569947&view=diff
> ==============================================================================
> --- httpd/httpd/branches/2.2.x/STATUS (original)
> +++ httpd/httpd/branches/2.2.x/STATUS Sun Aug 26 18:24:43 2007
> @@ -215,6 +215,25 @@
> http://svn.apache.org/viewvc?view=rev&revision=569622
> +1: niq, rpluem
>
> + * log core: ensure we use a special pool for stderr logging, so that
> + the stderr channel remains valid from the time plog is destroyed,
> + until the time the open_logs hook is called again. [William Rowe]
> + http://svn.apache.org/viewvc?view=rev&revision=569535
> + Backported to 2.2;
> + http://people.apache.org/~wrowe/r569535-backport-2.2.patch
> + +1: wrowe
> +
> + * mod_ssl: Version reporting update; displays 'compiled against'
> + Apache and build-time SSL Library versions at loglevel [info],
> + while reporting the run-time SSL Library version in the server
> + info tags. Helps to identify a mod_ssl built against one flavor
> + of OpenSSL but running against another (also adds SSL-C version
> + number reporting.) [William Rowe]
> + http://svn.apache.org/viewvc?view=rev&revision=520701
> + Backported to 2.2;
> + http://people.apache.org/~wrowe/r520701-backport-2.2.patch
> + +1: wrowe
> +
