Re: cvs commit: httpd-2.0/support apachectl.in
On Tue, Jul 16, 2002 at 08:30:41AM -, [EMAIL PROTECTED] wrote: martin 2002/07/16 01:30:41 Modified:support apachectl.in Log: If @APACHECTL_ULIMIT@ is used in apachectl.in, then something must replace it by a sensible (platform dependent?) value upon make install. Until that is done, $ULIMIT_MAX_FILES is set to the empty string so that apachectl does not cause a subsequent error @APACHECTL_ULIMIT@: not found This is replaced for me when I run configure, are you not using autoconf? In any case, if what is substituted for you right now doesn't work, we should fix it in autoconf, not remove the substitution from apachectl.in. -aaron
Re: cvs commit: httpd-2.0/support apachectl.in
On Mon, May 27, 2002 at 11:46:01AM -, [EMAIL PROTECTED] 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) FWIW, I think this simplification should be in .37. But, that's Cliff's call. And, we're most definitely still on .37-dev now, so we shouldn't have a CHANGES saying .38 yet. Whenever Cliff figures out what should go into .37, he can sort out the CHANGES file. -- justin
Re: cvs commit: httpd-2.0/support apachectl.in
Cliff Woolley [EMAIL PROTECTED] writes: On Tue, 28 May 2002, Justin Erenkrantz wrote: FWIW, I think this simplification should be in .37. But, that's Cliff's call. I agree, it will. It would be nice to have some agreement on what the big picture is by the time 2.0.37 is released. It may be appropriate for me to put back the traditional apachectl logic of generating its own help text if it doesn't understand what is passed in. I don't have an agenda here other than the desire to have a way to utilize any httpd option and at the same time not worry about whether or not the proper environment variables are picked up. The comments about apachectl being an init script were a necessary clue-by-four (ouch), but now the big picture is cloudy to me. If apachectl is the script that can pass anything through to httpd, then its user interface as an init script is marred because it can't give the proper feedback to the user when one of its keywords is misspelled. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: cvs commit: httpd-2.0/support apachectl.in
-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
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
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
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
[EMAIL PROTECTED] wrote: Switch back to SIGUSR1 for graceful restarts on all platforms that support it. This defines a symbol called AP_SIG_GRACEFUL in ap_config_auto.h which will have the appropriate signal value. All direct references to SIGWINCH have been replaced with AP_SIG_GRACEFUL. I thought Roy's desire for configurability was at runtime, not compiletime..? Uuugh, please no. I see no reason at all to make this runtime configurable. Bill
