You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Joshua Slive <jo...@slive.ca> on 2002/05/27 14:04:48 UTC
Re: cvs commit: httpd-2.0/support apachectl.in
trawick@apache.org wrote:
> trawick 02/05/27 04:46:01
>
> Modified: . CHANGES
> support apachectl.in
> Log:
> simplified apachectl...
>
> . it now uses "httpd -k verb" support for start/restart/etc.
> . it now can pass through any httpd option, so apachectl
> can be used as a replacement for invoking httpd directly
> (this practice ensures that any necessary environment
> variables are set up)
Looks good. If we are officially deprecating the non -k options, do we
want to warn the user? ie.
echo "Option 'start' is deprecated, use 'apachectl -k start'"
Joshua.
Re: apachectl/httpd compromise?
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 27 May 2002, Joshua Slive wrote:
>
> On Mon, 27 May 2002, William A. Rowe, Jr. wrote:
> > >- Having two different sets of arguments for httpd and apachectl is
> > >confusing and difficult to document
> >
> > How so? How is this different from syntax differences between any
> > other two commands? Here is a wrapper used by administrators for
> > five years, and you want to change the syntax "just because"?
>
> Because any time someone tells you to use command line option "-xxx" (to
> activate apache's porno mode, perhaps), you need to figure out where the
> heck it goes and how to get it there. I'm not saying it's the end of the
> world, I'm saying it's added complexity that we should remove if we can.
There should be a wrapper script that starts Apache in the proper
mode for "normally" running a given instance on a given system.
If they want to always have the porno mode enabled, then it should
be added to the configuration of that script, not specified on the
command line as an argument to that script.
If they want to start with porno mode just for some special testing,
then they need to be able to pass that command line option to httpd
somehow; in the past, this would just be by running it manually with
all the options. Since we now require other random stuff to be done
before running httpd, we either need a script that does that or we need
a way for the wrapper script to pass httpd options through.
The wrapper script, however, is not normally designed to be used
in a mode where a bunch of command line options are passed to it
every time it is run.
> The fact that apachectl's arguments are standard for init scripts was
> something I had forgotten about.
It isn't just that its arguments are standard for init scripts, it
_IS_ an init script.
I am wary of trying to overload it to be both an init script and
a magic-httpd-wrapper-that-takes-any-argument script. Some complexity
comes from having two different things that can be run, the init
script and the program itself directly. But I think even more
complexity comes from having one thing that magically plays both
roles, especially if it is not designed very carefully to play both
roles.
>
> > I have an entirely different approach we might want to consider. Rather
> > than implement -k, deprecate the -k flag in Win32. Apache takes no
> > arguments today, only options. Introducing a single argument doesn't
> > seem like a bad compromise.
>
> That was my favorite option from the beginning. But I'm not sure how easy
> it would be to implement with the currect getargs code.
I've never been a big fan of programs that take some arguments as
magic words on the command line, some as options, etc. There are
various standards for command line usage, and I don't know that having
command lines like "httpd start" fits into any of them. How is this
different than an init script taking a "start" option? Mostly a
matter of convention; init scripts are a well understood and widely
used concept, and generally only have the one argument passed to them
without a bunch of other command line options.
Re: apachectl/httpd compromise?
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 27 May 2002, William A. Rowe, Jr. wrote:
> >- Having two different sets of arguments for httpd and apachectl is
> >confusing and difficult to document
>
> How so? How is this different from syntax differences between any
> other two commands? Here is a wrapper used by administrators for
> five years, and you want to change the syntax "just because"?
Because any time someone tells you to use command line option "-xxx" (to
activate apache's porno mode, perhaps), you need to figure out where the
heck it goes and how to get it there. I'm not saying it's the end of the
world, I'm saying it's added complexity that we should remove if we can.
The fact that apachectl's arguments are standard for init scripts was
something I had forgotten about.
> I have an entirely different approach we might want to consider. Rather
> than implement -k, deprecate the -k flag in Win32. Apache takes no
> arguments today, only options. Introducing a single argument doesn't
> seem like a bad compromise.
That was my favorite option from the beginning. But I'm not sure how easy
it would be to implement with the currect getargs code.
Joshua.
apachectl/httpd compromise?
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:31 PM 5/27/2002, you wrote:
>On Mon, 27 May 2002, Sascha Schumann wrote:
>
> > > -0.9. Whoever said we were deprecating them? I thought the plan was
> that
> > > apachectl would continue to accept 'start|stop|restart' and would pass
> > > them as 'httpd -k $ARGV' to Apache. That is what apachectl does
> > > currently. Yes, you *could* say apachectl -k start with the new code and
> > > it would work (I see no problem with that), but where in there are we
> > > deprecating the old way? It sounds like just a convenience that -k
> works,
> > > not that it's the new preferred method. Getting rid of 'apachectl start'
> > > and friends seems pointless to me, and it will irritate countless admins
> > > to change it after so many years for no reason.
>
>Part of the point of the refactoring of apachectl was to get rid of two
>major problems:
>
>- Having two different sets of arguments for httpd and apachectl is
>confusing and difficult to document
How so? How is this different from syntax differences between any
other two commands? Here is a wrapper used by administrators for
five years, and you want to change the syntax "just because"?
>So yes, -k should be the new preferred method.
Preferred for apacectl? This change seems entirely gratuitous.
I have an entirely different approach we might want to consider. Rather
than implement -k, deprecate the -k flag in Win32. Apache takes no
arguments today, only options. Introducing a single argument doesn't
seem like a bad compromise.
So we review the Win32 code and accept either -k start or simply start.
And in the Unix port, we introduce httpd start [no -k flag whatsoever.]
Phase out the -k documentation for Win32 in favor of the simple verb.
If we wanted to allow httpd to stop itself by absolute PID, we could allow
a second argument, the daemon's ID [be it a PID on unix, or a service's
name on Win32.]
So simply,
httpd start
httpd stop
or more explicitly,
httpd stop 2914
or where 'named daemons' are supported,
[e.g. Win32, perhaps OSX at some point]
httpd stop Apache2
Thoughts?
Bill
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 27 May 2002, Marc Slemko wrote:
> It seems that the thing named "apachectl" has become something very
> very different from what it was created to be. The need to set certain
> environment variables before running httpd, and the need for a
> wrapper script that provides standard command line options to start/stop/etc
> processes, allows you to pass in the proper command line options, etc.
> are two quite different things.
OK. Let's go back to the original problem description:
- httpd can't be launched directly because of environment problems; we
need to do it through a shell script.
- The existing apachectl doesn't work for this because it doesn't allow
things like "httpd -v" to be run.
- It is a bad idea to keep adding more options to apachectl, because it
turns a simple shell script into a complicated program and makes it
confusing for users who need to deal with multiple sets of command line
options.
So it seems what Marc is suggesting is to retain a simple apachectl that
just answers the basic sysv-init type options, and calls a second program
(say, for argument, httpd.sh) that just sets the environment variables and
passes all arguments to httpd. I believe that this was one of Jeff's
earliest suggestions. The only problem with it is the proliferation of
silly little shell scripts that users need to figure out.
Anyway, having the "-k" options available is a clear win in any case. I
have no problem with either of those options for shell scripts.
Joshua.
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Marc Slemko <ma...@znep.com>.
On Mon, 27 May 2002, Joshua Slive wrote:
>
> On Mon, 27 May 2002, Sascha Schumann wrote:
>
> > > -0.9. Whoever said we were deprecating them? I thought the plan was that
> > > apachectl would continue to accept 'start|stop|restart' and would pass
> > > them as 'httpd -k $ARGV' to Apache. That is what apachectl does
> > > currently. Yes, you *could* say apachectl -k start with the new code and
> > > it would work (I see no problem with that), but where in there are we
> > > deprecating the old way? It sounds like just a convenience that -k works,
> > > not that it's the new preferred method. Getting rid of 'apachectl start'
> > > and friends seems pointless to me, and it will irritate countless admins
> > > to change it after so many years for no reason.
>
> Part of the point of the refactoring of apachectl was to get rid of two
> major problems:
>
> - Having two different sets of arguments for httpd and apachectl is
> confusing and difficult to document
You shouldn't be giving all sorts of random options to apachectl all
the time.
>
> - How do you pass additional command line arguments through apachectl?
> What will "apachectl -f /etc/httpd.conf start -D ReverseProxy" do?
> I believe the answer depends on the order of the arguments, which
> is truly nasty.
Erm, the point of a startup script is to give you a way to start
a program without having to remember a whole bunch of random command
line parameters every time. That is why apachectl was setup to let you
set whatever command line arguments, etc. you need in the script so
you only have to run the startup script, avoiding massive confusion
and errors when you don't quite specify the exact parameters on the
command line.
It seems that the thing named "apachectl" has become something very
very different from what it was created to be. The need to set certain
environment variables before running httpd, and the need for a
wrapper script that provides standard command line options to start/stop/etc
processes, allows you to pass in the proper command line options, etc.
are two quite different things.
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Joshua Slive <jo...@slive.ca>.
On Mon, 27 May 2002, Sascha Schumann wrote:
> > -0.9. Whoever said we were deprecating them? I thought the plan was that
> > apachectl would continue to accept 'start|stop|restart' and would pass
> > them as 'httpd -k $ARGV' to Apache. That is what apachectl does
> > currently. Yes, you *could* say apachectl -k start with the new code and
> > it would work (I see no problem with that), but where in there are we
> > deprecating the old way? It sounds like just a convenience that -k works,
> > not that it's the new preferred method. Getting rid of 'apachectl start'
> > and friends seems pointless to me, and it will irritate countless admins
> > to change it after so many years for no reason.
Part of the point of the refactoring of apachectl was to get rid of two
major problems:
- Having two different sets of arguments for httpd and apachectl is
confusing and difficult to document
- How do you pass additional command line arguments through apachectl?
What will "apachectl -f /etc/httpd.conf start -D ReverseProxy" do?
I believe the answer depends on the order of the arguments, which
is truly nasty.
So yes, -k should be the new preferred method.
>
> It would also defeat the current use of apachectl in the init
> process.
>
> # ln -s `which apachectl` /etc/rc.d/rc3.d/S30apache
Hmmm, I hadn't remembered that issue. That's a good point.
What about if we document "-k" as the preferred method, but leave
the other method available and do
echo "Executing httpd -k start"
so that it is clear what is going on?
Joshua.
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Sascha Schumann <sa...@apache.org>.
> -0.9. Whoever said we were deprecating them? I thought the plan was that
> apachectl would continue to accept 'start|stop|restart' and would pass
> them as 'httpd -k $ARGV' to Apache. That is what apachectl does
> currently. Yes, you *could* say apachectl -k start with the new code and
> it would work (I see no problem with that), but where in there are we
> deprecating the old way? It sounds like just a convenience that -k works,
> not that it's the new preferred method. Getting rid of 'apachectl start'
> and friends seems pointless to me, and it will irritate countless admins
> to change it after so many years for no reason.
It would also defeat the current use of apachectl in the init
process.
# ln -s `which apachectl` /etc/rc.d/rc3.d/S30apache
- Sascha
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Cliff Woolley <jw...@virginia.edu>.
On 27 May 2002, Jeff Trawick wrote:
> > Looks good. If we are officially deprecating the non -k options, do
> > we want to warn the user? ie.
> > echo "Option 'start' is deprecated, use 'apachectl -k start'"
>
> +1 from me
-0.9. Whoever said we were deprecating them? I thought the plan was that
apachectl would continue to accept 'start|stop|restart' and would pass
them as 'httpd -k $ARGV' to Apache. That is what apachectl does
currently. Yes, you *could* say apachectl -k start with the new code and
it would work (I see no problem with that), but where in there are we
deprecating the old way? It sounds like just a convenience that -k works,
not that it's the new preferred method. Getting rid of 'apachectl start'
and friends seems pointless to me, and it will irritate countless admins
to change it after so many years for no reason.
--Cliff
Re: cvs commit: httpd-2.0/support apachectl.in
Posted by Jeff Trawick <tr...@attglobal.net>.
Joshua Slive <jo...@slive.ca> writes:
> trawick@apache.org wrote:
> > trawick 02/05/27 04:46:01
> > Modified: . CHANGES
> > support apachectl.in
> > Log:
> > simplified apachectl...
> > . it now uses "httpd -k verb" support for start/restart/etc.
> > . it now can pass through any httpd option, so apachectl
> > can be used as a replacement for invoking httpd directly
> > (this practice ensures that any necessary environment
> > variables are set up)
>
>
> Looks good. If we are officially deprecating the non -k options, do
> we want to warn the user? ie.
> echo "Option 'start' is deprecated, use 'apachectl -k start'"
+1 from me
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...