Re: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Bill Stoddard <st...@raleigh.ibm.com>]

I don't think this assumption is as bad as it first appears -for Windows-.
I talked to Ken C. about it and he agrees. apachectl makes a similar
assumption about the location of the PID file. However, it is easy to change
apachectl, it is not easy to change apache.exe.

On the larger topic of keeping the windows cruft out of http_main.c... I
have pursued this main_win32 project precisely because most of the group
wanted to keep the Windows code out of http_main.c. I somewhat agree with
this direction, as long at it does not significantly impact the
maintainability and reliability of the Windows port.  I've made good
progress, but I'm not convinced it is ultimately the right thing to do. Take
a look at what I've done (yes it has warts) and give me some feedback.

Here are the alternatives I've though of:
Option 1 - Assume the relative location of the pid file is constant (what
I've done)
It's simple and will probably cover 99.9% (if not more) of the typical
windows users (speak up out there if you are an Apache for Windows user and
you disagree.)

Option 2 - Read the config file in apache.exe
I have this working, but I'm not convinced the ability to put the pid file
anywhere is worth writing ugly error prone code to do so

Option 3 - Move all this Windows shit back to http_main.c
Maybe...

Option 4 - Require the used to pass in a PID in addition to the
start/restart signal
E.g., apache -k restart 123456. Only problem is it is difficult to know
which is the parent and which is the child.

Option 5 - Do something goofy with the registry
Don't like this at all.

Option 6 - Pass the -k options to the Windows MPM via environment variables
and handle this directly in the MPM

All of these options have their strengths and weaknesses.

Bill

----- Original Message -----
From: Ryan Bloom <rb...@raleigh.ibm.com>
To: <ne...@apache.org>
Cc: <ap...@apache.org>
Sent: Friday, December 17, 1999 5:34 PM
Subject: Re: cvs commit: apache-2.0/src/os/win32 main_win32.c


>
> >   Windows:
> >   Some more work to properly handle -k restart,shutdown. I have made a
simplifying
> >   assumption that the relative name of the server pidfile is always
logs/httpd.pid.
> >   This saves the error prone effort of reading the config file in
apache.exe (as
> >   opposed to ApacheCore.dll). I am really working hard to keep Windows
specific
> >   junk out of http_main.c.
>
> I disagree with this assumption.  If somebody wants to change where the
> pidfile is stored, then we have to be able to deal with it.  If that means
> putting some Windows specific stuff in http_main, then so be it.  There
> are other ways to do this as well (I need to think them through more, and
> do some more research about Windows before I post about them).  I am -1
> for this patch, unless it is a stop-gap solution so we can get 2.0 working
> on Windows until we fix this the right way.
>
> Ryan
>
>

Re: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Manoj Kasichainula <ma...@io.com>]

On Mon, Dec 20, 1999 at 09:18:58AM -0500, Ryan Bloom wrote:
> #ifdef WIN32
>     case 'k':
>         server_restart(ap_pidfile);
>     case ...
> #endif

Actually, I might like to see -k {shutdown,restart} supported on Unix
as well. Because of Linux 2.0, not all platforms can support SIGUSR1
for graceful restart. Because of other older platforms, I don't think
all platforms can support SIGWINCH either (though I haven't checked;
I've just heard that it's a relatively new addition to Unixland). I
haven't found a sutiable substitute signal that's available on all
platforms, so apache -k blah (or better yet, a compiled replacement
for apachectl) might make sense on Unix as well.

Of course, this might be unnecessary if we can eliminate the unsightly
ungraceful restart and ungraceful shutdown, but this might not be
practical.

Manoj

Re: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Bill Stoddard <st...@raleigh.ibm.com>]

> > On the larger topic of keeping the windows cruft out of http_main.c... I
> > have pursued this main_win32 project precisely because most of the group
> > wanted to keep the Windows code out of http_main.c. I somewhat agree
with
> > this direction, as long at it does not significantly impact the
> > maintainability and reliability of the Windows port.  I've made good
> > progress, but I'm not convinced it is ultimately the right thing to do.
Take
> > a look at what I've done (yes it has warts) and give me some feedback.
>
> I think the goal of keeping all of the windows cruft out of http_main.c is
> the wrong goal.  The correct goal should be to keep MOST of the cruft out.
> I still like the solution I originally proposed.  Namely,  create a couple
> of functions in the main_win32 project that do all of the dirty work, and
> call those functions in the appropriate places from http_main.c, ifdef'ing
> them out on non-win32 platforms.
>
...
> c = ap_getopt(...)
>    switch (c)
> ...
> #ifdef WIN32
>     case 'k':
>         server_restart(ap_pidfile);
>     case ...
> #endif
>
Best suggestion I've seen so far. Handling the -k option is by far the
stickiest issue and this hits a nice compromise.

Bill

Re: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Ryan Bloom <rb...@raleigh.ibm.com>]

> On the larger topic of keeping the windows cruft out of http_main.c... I
> have pursued this main_win32 project precisely because most of the group
> wanted to keep the Windows code out of http_main.c. I somewhat agree with
> this direction, as long at it does not significantly impact the
> maintainability and reliability of the Windows port.  I've made good
> progress, but I'm not convinced it is ultimately the right thing to do. Take
> a look at what I've done (yes it has warts) and give me some feedback.

I think the goal of keeping all of the windows cruft out of http_main.c is
the wrong goal.  The correct goal should be to keep MOST of the cruft out.
I still like the solution I originally proposed.  Namely,  create a couple
of functions in the main_win32 project that do all of the dirty work, and
call those functions in the appropriate places from http_main.c, ifdef'ing
them out on non-win32 platforms.

I envision this:

win32_main project:

void server_restart(char *pidfilename) {

CreateEvent(...)
SignalEvent(...)
}

http_main.c

c = ap_getopt(...)
   switch (c)
...
#ifdef WIN32
    case 'k':
        server_restart(ap_pidfile);
    case ...
#endif

This seems to keep all but a few lines out of the main-line code, but
leaves us with the most flexability for the server.  It doesn't really
even impact the readability of the code.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		

Come to the first official Apache Software Foundation
Conference!  <http://ApacheCon.Com/>

Re: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Bill Stoddard <st...@raleigh.ibm.com>]

> | Option 1 - Assume the relative location of the pid file is constant
(what
> | I've done)
> | It's simple and will probably cover 99.9% (if not more) of the typical
> | windows users (speak up out there if you are an Apache for
>
> This breaks multiple services on the same box, it is not a good idea.
This does not break multiple services.  The -relative location- is
logs/httpd.pid. The absolute location is SERVER_ROOT/logs/httpd.pid. And I
use your technique to resolve server_root (see below).

>
> | Option 5 - Do something goofy with the registry
> | Don't like this at all.
> |
> | Option 6 - Pass the -k options to the Windows MPM via environment
> | variables
> | and handle this directly in the MPM
>
> Don't know what has survived in Apache 2.0, but I solved this
> problem in the 1.3 tree.  Finding the right pid file is only
> a matter of finding which conf the user intends to signal.
> Apache 1.3 tries five different locations, in this order:

Yes, I am using this (with implementation tweaks) in Apache 2.0.

All option 1 prevents is the use of the PidFile directive in the
configuration file (i.e., assumes that it will ALWAYS be logs/httpd.pid).

Bill

RE: cvs commit: apache-2.0/src/os/win32 main_win32.c

[Keith Wannamaker <kr...@raleigh.ibm.com>]

| Option 1 - Assume the relative location of the pid file is constant (what
| I've done)
| It's simple and will probably cover 99.9% (if not more) of the typical
| windows users (speak up out there if you are an Apache for

This breaks multiple services on the same box, it is not a good idea.

| Option 5 - Do something goofy with the registry
| Don't like this at all.
|
| Option 6 - Pass the -k options to the Windows MPM via environment
| variables
| and handle this directly in the MPM

Don't know what has survived in Apache 2.0, but I solved this
problem in the 1.3 tree.  Finding the right pid file is only
a matter of finding which conf the user intends to signal.
Apache 1.3 tries five different locations, in this order:

    /* ServerConfFile is found in this order:
     * (1) -f or -n
     * (2) [-d]/SERVER_CONFIG_FILE
     * (3) ./SERVER_CONFIG_FILE
     * (4) [Registry: HKLM\Software\[product]\ServerRoot]/SERVER_CONFIG_FILE
     * (5) /HTTPD_ROOT/SERVER_CONFIG_FILE
     */

where SERVER_CONFIG_FILE and HTTPD_ROOT are the appropriate #defines.
It seems like this sequence is a merger of your options 5 and 6
and is already a proven, useful solution to this problem; maybe
Apache 2.0 ought to just follow suit.

Keith Wannamaker
IBM HTTP Server Development