Tom Donovan wrote:
With an earlier patch from comment #6 in bug 43534, mod_perl and the
Apache window seem fine in all startup cases I can think to try - but
there is a concern about exactly when stdout gets directed to the null
device.
I don't quite follow this concern - but I'm sure there is a history
somewhere. Is there a bug, post, or test case which shows the problem
with delaying this redirection of stdout on Windows? I can't seem to
find the history of this concern searching Bugzilla (back to change
r88358 in Feb, 2001) or the apache-dev archives.
Nope, it was a design decision early on by the original authors. The
goal was always to present configuration errors on the first-pass to
the end user at the console, and then daemonize.
Ryan and Jeff in particular noted that many fds 'leaked' into any extra
spawned processes, such as cgid etc, if the console was still open. It
would not successfully daemonize (completely). So this was moved from
the post config phase to the pre config phase. Some errors are still
reported, but many cannot be. It's a bad design but something that
perhaps should be addressed in 2.4 across all platforms, where there's
lots of attention during the alpha/beta.
Now to Win32, again it's a design consideration; early tests had all
sorts of traumatic failures when we couldn't even use file stdout, stdin
or stderr and httpd expects those to exist. Service processes have all
NULL handles in these cases. So open-early became the strategy and I
refactored those into the actual pre-argv[] processing phase.
Back to consoles; you'll see there were many stages of evolution if you
review the svn history. Tweaks and new components for 9x, for NT, and
so forth. Never entirely rationalized because httpd is a daemon, on
win32 a daemon is a service, ergo httpd should not be run in a console
since it would 'go away' upon logout. Only a dev who fronts a localized
webapp for the logged in user would ever want to treat it as such. Of
course it's a fun mode for local development and testing.
Your patch worked in conjunction with that iteration of httpd for one
of a couple of possible reasons. Perhaps the console handles were not
effectively closed, and some duplicate hung around. Perhaps one of
the handles like stdin hung around, which was changed in behavior
between 2.2.4 and 2.2.7. I'm not entirely certain, but I am sure that
the handles of the daemonized process are now properly closed; and this
leads to the console really paying no attention at all.
START httpd goes into it's goofy mode because it has no interactive
behavior, but has no cmd to exit to, and cmd sees it's process is still
running. start -k httpd should not exhibit this behavior. If there was
a start -hide -k httpd, it wouldn't be offensive.
I'm thinking of a scenario where the console *parent only* and on win32
might hold onto the stdin handle. I'll research and reply.
Bill
