Re: is httpd a valid way to start Apache?
On Thu, May 16, 2002 at 10:16:56PM -0701, Jos Backus wrote: On Thu, May 16, 2002 at 07:27:46PM -0700, Manoj Kasichainula wrote: I've (mostly) written replacements for supervise, setuidgid, and tcpserver. They use Single Unix APIs, haven't been ported to APR, and have no docs yet, but they are working for me. I imagine porting them to APR wouldn't be too painful, though they wouldn't remain the svelte 4-8kB binaries they are today. :) Interesting. I'm not sure how much benefit there would be from using APR though. Mainly portability to older Unixes that don't support some of the more modern calls I used (or that break Single Unix in ways that Linux doesn't). I guess autoconf, etc. would do the job as well. Are people interested in this code? I for one would be interested in seeing this. http://www.io.com/~manoj/file/mktool-0.0.7.tar.gz I've only built it on my Linux boxes; I haven't even tried FreeBSD yet, though I did try to avoid Linuxisms. The supervise replacement is called babysit (so it wouldn't be confused with the djb tool it tries to work as). I'll hopefully clean it up a bit more, and maybe even test and doc it more next week. I may be able to sell this to the FreeBSD people for inclusion in the base OS if the license allows it. That won't be a problem. :) Do you also have equivalents to svc, svstat and svok? I haven't written svc or svstat replacements yet; I've just used 'echo -n dx directory/control' in my scripts in the mean time. But they will be easy. There is an svok workalike called bsok in the tarball though.
Re: is httpd a valid way to start Apache?
Justin Erenkrantz wrote: I know that libtool can (supposedly) relink binaries to change the link paths. Could that be something we could do? I don't think that libtool has any magic that will produce a major breakthrough here. I played around with it back when binbuild was totally non-functional, and was underwhelmed. Greg
Re: is httpd a valid way to start Apache?
On 16 May 2002, Jeff Trawick wrote: Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. +1 That looks good to me. Really, I have no particular problem with httpd being the wrapper script, but it would certainly cause more disruption to existing setups. A couple points of clarification: - I think I would recommend a This is deprecated message for the non -k options so that they don't need to be documented and supported indefinitely. Then we can make it clear that there is only one true set of command line options and they apply both to apachectl and httpd. - httpd -k restart and httpd -k graceful should do a config check before restarting and refuse to restart if the config is not valid. Joshua.
Re: is httpd a valid way to start Apache?
Joshua Slive wrote: On 16 May 2002, Jeff Trawick wrote: Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. +1 That looks good to me. Really, I have no particular problem with httpd being the wrapper script, but it would certainly cause more disruption to existing setups. A couple points of clarification: - I think I would recommend a This is deprecated message for the non -k options so that they don't need to be documented and supported indefinitely. Then we can make it clear that there is only one true set of command line options and they apply both to apachectl and httpd. - httpd -k restart and httpd -k graceful should do a config check before restarting and refuse to restart if the config is not valid. Joshua.
RE: is httpd a valid way to start Apache?
My own opinion is that we leave things exactly as they are today. If you are running the binary by hand, you are taking some responsibility for knowing what you are doing. That means having the environment variables setup correctly before you start. If you don't want that responsibility, use apachectl to run the server. Trying to solve this problem any other way just seems like we are asking for trouble. Ryan -- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA -Original Message- From: [EMAIL PROTECTED] [mailto:trawick@rdu88-251- 253.nc.rr.com] On Behalf Of Jeff Trawick Sent: Thursday, May 16, 2002 7:35 AM To: [EMAIL PROTECTED] Subject: Re: is httpd a valid way to start Apache? Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. 1) httpd can't be used directly on Unix because of environment variable settings or shouldn't, take your pick; I suspect that we're better off if httpd doesn't work anymore without some magic that people debugging it would know (maybe AP_DEBUG allows it to work directly) (Personally I'd prefer that httpd is the wrapper script, but I see one person definitely against that and one person definitely for apachectl being the wrapper script.) 2) httpd picks up the following function from apachectl: a) apachectl start - httpd -k start (it is different from plain httpd) b) apachectl startssl - httpd -DSSL -k start c) apachectl stop - httpd -k stop d) apachectl restart - httpd -k restart e) apachectl graceful - httpd -k graceful 3) apachectl becomes a simple wrapper script for httpd for the time being, most existing apachectl features will be mapped to their httpd equivalents a) apachectl configtest is mapped to the existing httpd -t invocation b) the apachectl commands listed above are translated into their new httpd equivalents, but generally we expect to pass the command-line through verbatim to httpd the following features are lost: a) apachectl fullstatus b) apachectl status c) apachectl help -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
Joshua Slive wrote: On 16 May 2002, Jeff Trawick wrote: Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. +1 That looks good to me. Really, I have no particular problem with httpd being the wrapper script, but it would certainly cause more disruption to existing setups. What Joshua said. This is going to be somewhat disruptive no matter which way we go, including doing nothing. Greg
RE: is httpd a valid way to start Apache?
On Thu, 16 May 2002, Ryan Bloom wrote: My own opinion is that we leave things exactly as they are today. If you are running the binary by hand, you are taking some responsibility for knowing what you are doing. That means having the environment variables setup correctly before you start. If you don't want that responsibility, use apachectl to run the server. Trying to solve this problem any other way just seems like we are asking for trouble. I think that is exactly what this proposal is saying. But at the same time it is cleaning up apachectl and adding some useful functionality to httpd. As I've said, the current apachectl is over-complicated and the split between apachectl and httpd is confusing to some people. This change would clear that up. JOshua.
RE: is httpd a valid way to start Apache?
Jeff Trawick wrote: Who would be in favor of this, or parts thereof? I'm anxious to see a consensus so that steps toward the goal can be filled in over time. 1) httpd can't be used directly on Unix because of environment variable settings SNIP Due to inheritance (export) of environment variables I usually start Apache after doing a: # for i in `export | cut -f3 -d' '|cut -f1 -d'='`; do export -n $i; done Which cleans them all up nicely. One reason for doing this is so that phpinfo() shows all these nice Enviroment variables which could reveal one thing or the other of some persons setup. Maybe it's an idea to let the 'startup' program (may it be httpd or apachectl) to filter these environment variables too ? they also take up memory, oooh ah :) Greets, Jeroen
RE: is httpd a valid way to start Apache?
My own opinion is that we leave things exactly as they are today. If you are running the binary by hand, you are taking some responsibility for knowing what you are doing. That means having the environment variables setup correctly before you start. If you don't want that responsibility, use apachectl to run the server. Trying to solve this problem any other way just seems like we are asking for trouble. I think that is exactly what this proposal is saying. But at the same time it is cleaning up apachectl and adding some useful functionality to httpd. As I've said, the current apachectl is over-complicated and the split between apachectl and httpd is confusing to some people. This change would clear that up. Various distros out there are also choosing to not even include apachectl and instead include their own init.d start/stop script which invariably is less powerful and sometimes plain wrong. It would be nice to include some of that logic in the binary itself to give the package maintainers less bullets for their feet. -Rasmus
Re: is httpd a valid way to start Apache?
Ryan Bloom [EMAIL PROTECTED] writes: My own opinion is that we leave things exactly as they are today. If you are running the binary by hand, you are taking some responsibility for knowing what you are doing. That means having the environment variables setup correctly before you start. If you don't want that responsibility, use apachectl to run the server. Trying to solve this problem any other way just seems like we are asking for trouble. One aspect of these changes is that they resolve existing problems with apachectl: . apachectl doesn't give you full access to everything that you need (all command-line options) . apachectl doesn't take into account the possible movement of the pid file I don't think we can truthfully tell Joe User use apachectl and everything will work. You can't even get the server version out of apachectl. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
Cliff Woolley [EMAIL PROTECTED] writes: 3) apachectl becomes a simple wrapper script for httpd You could do both 2 and 3 I suppose, but ... nah. #2 is enough to remove the complexity from apachectl. Step 3 is what removes the complexity from apachectl. Step 2 is what gives httpd the features required for step 3. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
On 16 May 2002, Jeff Trawick wrote: Step 3 is what removes the complexity from apachectl. Step 2 is what gives httpd the features required for step 3. I guess I don't see: start) stop) graceful) restart) httpd -k $1 ;; startssl) httpd -DSSL -k start ;; or whatever the syntax is for #2 alone as very complex. The complexity to which I was referring was that right now apachectl has to know where the PID file is, read the PID file, kill that pid, etc, etc. I'll just say +0 to #3. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
RE: is httpd a valid way to start Apache?
On Thu, 16 May 2002, Joshua Slive wrote: On Thu, 16 May 2002, Ryan Bloom wrote: My own opinion is that we leave things exactly as they are today. If you are running the binary by hand, you are taking some responsibility for knowing what you are doing. That means having the environment variables setup correctly before you start. If you don't want that responsibility, use apachectl to run the server. Trying to solve this problem any other way just seems like we are asking for trouble. I think that is exactly what this proposal is saying. But at the same time it is cleaning up apachectl and adding some useful functionality to httpd. As I've said, the current apachectl is over-complicated and the split between apachectl and httpd is confusing to some people. This change would clear that up. Would it make sense to move the httpd binary to .../libexec/httpd? That makes it clear that this is an internal binary which you shouldn't run directly, unless you're really smart. Then apachectl stays in .../sbin/. [Idea courtesy of mysql's mysqld.] Later, scott
Re: is httpd a valid way to start Apache?
Hello, JMDue to inheritance (export) of environment variables I usually start JMApache after doing a: JM# for i in `export | cut -f3 -d' '|cut -f1 -d'='`; do export -n $i; done JMWhich cleans them all up nicely. One reason for doing this is so that JMphpinfo() shows all these nice Enviroment variables which could reveal JMone thing or the other of some persons setup. Maybe it's an idea to let JMthe 'startup' program (may it be httpd or apachectl) to filter these JMenvironment variables too ? they also take up memory, oooh ah :) In our production environment we also include such functionality in our apachectl script. For some variables (LD_LIBRARY_PATH for example) it is essential to do this to make sure things will work, and for others (say, PATH) it's just annoying to pick up different values depending on who su'ed before starting a server. However, I don't know that this should be in the default Apache distribution. Often you'd want (or need) LD_LIBRARY_PATH or PATH or even ORACLE_HOME to be inherited on purpose (hence PassEnv). By the way, as someone who maintains Apache installations on many platforms, I definitely like moving the pidfile checking out of apachectl. I like the httpd -k idea to simplify apachectl. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 12:49:46PM -0701, Jos Backus wrote: What about moving into the other direction and moving the process management portion into a separate set of tools so it can be used with other daemons besides httpd? I've pondered writing something like this, but then I also ponder the opposite. Why not build the supervise support into httpd itself. httpd would listen on a unix-domain socket or FIFO in the filesystem, and all graceful signals would be replaced with writes to this fifo. This eliminates the crufty signal layer between the supervise replacement and httpd, completely hides the difference between Unix and Windows (using the -k syntax) and potentially allows for more interesting status reporting from the command-line. Probably not viable for 2.0, though. It would be great to have a BSD-licensed version of something like djb's daemontools. I've (mostly) written replacements for supervise, setuidgid, and tcpserver. They use Single Unix APIs, haven't been ported to APR, and have no docs yet, but they are working for me. I imagine porting them to APR wouldn't be too painful, though they wouldn't remain the svelte 4-8kB binaries they are today. :) On Wed, May 15, 2002 at 07:15:47PM -0701, Jos Backus wrote: Seriously, a decent process controller that would allow starting, stopping and sending various signals to a command that runs as its child (i.e. duplicating supervise's functionality) should not be too hard to implement. Nope, it wasn't. Assuming mine works, anyway. It's the fiddling with the pipes between two supervise's (the main one and the log/ one) that seems tricky to me. I don't think this is a problem, because of the way Unix mangles the file descriptors. If you do something like: supervise /var/supervise/producer | supervise /var/supervise/consumer then, your shell will arrange the fd's so that stdout for producer points to a pipe to stdin for consumer. Then, when the supervise processes fork-exec their children, the kids inherit the 2 ends of the pipe, and just use them as if the pipe were set up just for them. If the producer dies, there's no problem, because the parent supervise still keeps an fd for that end of the pipe and passes it on to the next generation of the producer. Same goes for the consumer. It might be nice to use a technique like this to take the code for reliable piped logging out of httpd and make it more generally useful. And I'd not sure how you'd wait() for the child while still being able to select() on a name pipe in order to read control messages sent by svc. In my supervise replacement, I use a technique picked up from the Awesome Might that is Dean (and which was used in some of the early MPMs). Create a pipe, and keep both ends of it. Create a signal handler for SIGCHLD that writes to the pipe. And, in the select() call you reference, wait on both the sigchld pipe (a.k.a. pipe_of_death) and the named fifo. Are people interested in this code?
Re: is httpd a valid way to start Apache?
On Thu, May 16, 2002 at 05:00:13PM +0200, Jeroen Massar wrote: Due to inheritance (export) of environment variables I usually start Apache after doing a: # for i in `export | cut -f3 -d' '|cut -f1 -d'='`; do export -n $i; done Which cleans them all up nicely. You can also do this by running httpd under env -, which I believe is quite portable. man env(1) for details.
Re: is httpd a valid way to start Apache?
On Thu, May 16, 2002 at 07:27:46PM -0700, Manoj Kasichainula wrote: On Wed, May 15, 2002 at 12:49:46PM -0701, Jos Backus wrote: It would be great to have a BSD-licensed version of something like djb's daemontools. I've (mostly) written replacements for supervise, setuidgid, and tcpserver. They use Single Unix APIs, haven't been ported to APR, and have no docs yet, but they are working for me. I imagine porting them to APR wouldn't be too painful, though they wouldn't remain the svelte 4-8kB binaries they are today. :) Interesting. I'm not sure how much benefit there would be from using APR though. supervise /var/supervise/producer | supervise /var/supervise/consumer Thanks for the nice explanations. In my supervise replacement, I use a technique picked up from the Awesome Might that is Dean (and which was used in some of the early MPMs). Create a pipe, and keep both ends of it. Create a signal handler for SIGCHLD that writes to the pipe. And, in the select() call you reference, wait on both the sigchld pipe (a.k.a. pipe_of_death) and the named fifo. This sounds like the self-pipe trick (see http://cr.yp.to/docs/selfpipe.html). Neat. Are people interested in this code? I for one would be interested in seeing this. I may be able to sell this to the FreeBSD people for inclusion in the base OS if the license allows it. Do you also have equivalents to svc, svstat and svok? -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 02:17:55PM -0400, Jeff Trawick wrote: If httpd is to be left as-is on Unix (i.e., maybe it works maybe it doesn't), then perhaps apachectl needs to be pushed as the way to access all httpd functionality. One thing that I seem to recall is that we've talked about taking the apachectl functionality and moving it into httpd (the C program that is - not renaming apachectl as httpd). So, you can do: httpd -k start httpd -k stop httpd -k graceful (ISTR that -k was the option in Win32 and for various reasons, we wanted to use that to indicate the command to run.) Is there any reason that httpd couldn't read/parse/source envvars file itself? That sort of sucks, but perhaps that's a way to get around this? -- justin
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 11:21:04AM -0700, Justin Erenkrantz wrote: Is there any reason that httpd couldn't read/parse/source envvars file itself? That sort of sucks, but perhaps that's a way to get around this? -- justin Naw, you get dynamic linking failures as soon as you exec() the process. -aaron
Re: is httpd a valid way to start Apache?
Justin Erenkrantz [EMAIL PROTECTED] writes: On Wed, May 15, 2002 at 02:17:55PM -0400, Jeff Trawick wrote: If httpd is to be left as-is on Unix (i.e., maybe it works maybe it doesn't), then perhaps apachectl needs to be pushed as the way to access all httpd functionality. One thing that I seem to recall is that we've talked about taking the apachectl functionality and moving it into httpd (the C program that is - not renaming apachectl as httpd). So, you can do: httpd -k start httpd -k stop httpd -k graceful (ISTR that -k was the option in Win32 and for various reasons, we wanted to use that to indicate the command to run.) Is there any reason that httpd couldn't read/parse/source envvars file itself? That sort of sucks, but perhaps that's a way to get around this? -- justin It can, and that would fix certain things, like the OS/390 and AIX example of needing to tune the memory use to allow lots of threads. (Though I wonder how it would find the right copy of envvars in a binbuild situation.) Unfortunately, it wouldn't fix the inability of a binbuild httpd from finding its libraries. A wrapper script seems to cover both types of problems. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 11:26:42AM -0700, Aaron Bannert wrote: Naw, you get dynamic linking failures as soon as you exec() the process. Yeah, that's true. Moving the start/restart logic into httpd still seems worthy though. I know that libtool can (supposedly) relink binaries to change the link paths. Could that be something we could do? Using a shell script is going to cause more problems than it helps - I like being able to do: gdb /usr/local/apache2/bin/httpd core.file Mozilla went down this route of a fake binary - I'm not sure I like that approach. -- justin
Re: is httpd a valid way to start Apache?
At 01:26 PM 5/15/2002, you wrote: On Wed, May 15, 2002 at 11:21:04AM -0700, Justin Erenkrantz wrote: Is there any reason that httpd couldn't read/parse/source envvars file itself? That sort of sucks, but perhaps that's a way to get around this? -- justin Naw, you get dynamic linking failures as soon as you exec() the process. Because it's not found... question; is it possible to link the .so's with a path of ./libfoo.so rather than /long/path/to/libfoo.so? Drop the libs in with the binaries and away you go? Just a thought. Bill
Re: is httpd a valid way to start Apache?
Justin Erenkrantz [EMAIL PROTECTED] writes: On Wed, May 15, 2002 at 11:26:42AM -0700, Aaron Bannert wrote: Naw, you get dynamic linking failures as soon as you exec() the process. Yeah, that's true. Moving the start/restart logic into httpd still seems worthy though. yeah I know that libtool can (supposedly) relink binaries to change the link paths. Could that be something we could do? Wouldn't we have to do a full link-edit on the target machine to make that work portably? One of the nice things about binbuilds is that we don't give a rip whether the user has a working ld (just an example). We don't want to care whether or not somebody has working binutils. Using a shell script is going to cause more problems than it helps - I like being able to do: gdb /usr/local/apache2/bin/httpd core.file How many problems does it cause? Having to give gdb a different name is a problem (minor), but how many others are there? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 02:44:37PM -0400, Jeff Trawick wrote: Wouldn't we have to do a full link-edit on the target machine to make that work portably? One of the nice things about binbuilds is that we don't give a rip whether the user has a working ld (just an example). We don't want to care whether or not somebody has working binutils. I'm not sure what's involved on each platform. I think I remember reading on some platforms, libtool could be tricky and do it without needing a full recompile or relink (it just modifies the binary itself). I'm not sure if that's even possible or not (doesn't seem so). But, yeah, I could see it causing problems on esoteric platforms. Perhaps libtool 1.4.x can do this better than 1.3? How many problems does it cause? Having to give gdb a different name is a problem (minor), but how many others are there? ps and other process utilities won't filter on httpd. ps -C httpd, pkill -HUP httpd would all fail if the binary isn't called httpd. Perhaps we could so some sort of transformation for binbuilds that only adds the httpd.bin to those distributions. -- justin
Re: is httpd a valid way to start Apache?
On Wed, 15 May 2002, Justin Erenkrantz wrote: pkill -HUP httpd would all fail if the binary isn't called httpd. Erm... that isn't a bad thing.
Re: is httpd a valid way to start Apache?
Justin Erenkrantz [EMAIL PROTECTED] writes: How many problems does it cause? Having to give gdb a different name is a problem (minor), but how many others are there? ps and other process utilities won't filter on httpd. ps -C httpd, pkill -HUP httpd would all fail if the binary isn't called httpd. gotcha (but I'm used to lt-httpd by now anyway :) ) Perhaps we could so some sort of transformation for binbuilds that only adds the httpd.bin to those distributions. -- justin That is doable, and covers the most serious problem, but on platforms where other environment variables are needed it won't solve the remaining problems, so apachectl will still need to source envvars. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
William A. Rowe, Jr. wrote: At 01:26 PM 5/15/2002, you wrote: On Wed, May 15, 2002 at 11:21:04AM -0700, Justin Erenkrantz wrote: Is there any reason that httpd couldn't read/parse/source envvars file itself? That sort of sucks, but perhaps that's a way to get around this? -- justin Naw, you get dynamic linking failures as soon as you exec() the process. Because it's not found... question; is it possible to link the .so's with a path of ./libfoo.so rather than /long/path/to/libfoo.so? Drop the libs in with the binaries and away you go? Just a thought. Hrm... or maybe an Apache loader. Basically, a bogus executable that sets up everything for the actual server itself. Nasty. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ A society that will trade a little liberty for a little order will lose both and deserve neither - T.Jefferson
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 11:55:37AM -0700, Marc Slemko wrote: On Wed, 15 May 2002, Justin Erenkrantz wrote: pkill -HUP httpd would all fail if the binary isn't called httpd. Erm... that isn't a bad thing. I'm assuming you mean that I should *only* do: ps -p `cat /where/my/pid/file/that/i/placed/in/my/conf/file/is` kill -HUP `cat /where/my/pid/file/that/i/placed/in/my/conf/file/is` There's more than one way to skin the poor cat. -- justin
Re: is httpd a valid way to start Apache?
On Wed, 15 May 2002, Justin Erenkrantz wrote: How many problems does it cause? Having to give gdb a different name is a problem (minor), but how many others are there? ps and other process utilities won't filter on httpd. ps -C httpd, pkill -HUP httpd would all fail if the binary isn't called httpd. Perhaps we could so some sort of transformation for binbuilds that only adds the httpd.bin to those distributions. -- justin Hmmm... don't like inconsistency in distributions. What about - Incorporate the restart stuff into httpd - Make apachectl a simple shell script that just sets up the environment and calls httpd - Encourage everyone to use apachectl This makes it much clearer that there is a binary (httpd) that needs to be used for ps/pkill/gdb, and a seperate control program. It also solves the problem that the current apachectl is over-complicated and confusing to some users. Problems with current apachectl include: - there are two sets of command line options: httpd and apachectl, and it is difficult to tell which ones go where - apachectl needs to know the location of the pid file, and users don't understand they need to edit this when they change their configuration Joshua.
Re: is httpd a valid way to start Apache?
Joshua Slive [EMAIL PROTECTED] writes: What about - Incorporate the restart stuff into httpd - Make apachectl a simple shell script that just sets up the environment and calls httpd - Encourage everyone to use apachectl Would the syntax for start/restart/configtest be exactly the same as current apachectl, or would it be changed? (I think it would be changed to use -k keyword for apachectl options that don't correspond directly to existing httpd options.) If the syntax changes, then maybe 1) apachectl remains for a while but is deprecated; it shrinks to something that translates between existing apachectl syntax and the new httpd options 2) a new script called apache sets up the environment and calls httpd; its command-line syntax is exactly the same as httpd (oh, Apache isn't just the Apache httpd server? I guess this name isn't so good) 3) httpd is the binary which we don't want anybody to run directly unless they know what they are doing -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: is httpd a valid way to start Apache?
What about moving into the other direction and moving the process management portion into a separate set of tools so it can be used with other daemons besides httpd? This would also improve portability of the mechanism: no worries about pid file races and staleness, differing versions of ps/kill/killall/etc. It would be great to have a BSD-licensed version of something like djb's daemontools. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Re: is httpd a valid way to start Apache?
On 15 May 2002, Jeff Trawick wrote: Joshua Slive [EMAIL PROTECTED] writes: What about - Incorporate the restart stuff into httpd - Make apachectl a simple shell script that just sets up the environment and calls httpd - Encourage everyone to use apachectl Would the syntax for start/restart/configtest be exactly the same as current apachectl, or would it be changed? (I think it would be changed to use -k keyword for apachectl options that don't correspond directly to existing httpd options.) It would be very nice if httpd graceful could be made a synonym for httpd -k graceful, but I don't think the current getopt stuff will handle that. Otherwise, I would favor an apachectl that looks something like #!/bin/sh # pick up any necessary environment variables if test -f @exp_bindir@/envvars; then . @exp_bindir@/envvars fi case $@ in start) shift 1 ;; stop) COMMAND=-k stop shift 1 ;; graceful) COMMAND=-k graceful shift 1 ;; # etc... httpd $COMMAND $@ (Please excuse the horrible shell script, but you get the point.) Possibly with a this is deprecated please use -k message in the appropriate places. This is not perfectly compatible with apachectl, but it is pretty close, and very much simpler. Joshua.
Re: is httpd a valid way to start Apache?
On Wed, May 15, 2002 at 12:49:46PM -0701, Jos Backus wrote: What about moving into the other direction and moving the process management portion into a separate set of tools so it can be used with other daemons besides httpd? This would also improve portability of the mechanism: no worries about pid file races and staleness, differing versions of ps/kill/killall/etc. It would be great to have a BSD-licensed version of something like djb's daemontools. That would be totally fine/cool. Are you volunteering? :-) Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: is httpd a valid way to start Apache?
I wrote: It would be great to have a BSD-licensed version of something like djb's daemontools. That would be totally fine/cool. Are you volunteering? :-) I would if I was even half as decent a programmer as some of you :-) Seriously, a decent process controller that would allow starting, stopping and sending various signals to a command that runs as its child (i.e. duplicating supervise's functionality) should not be too hard to implement. It's the fiddling with the pipes between two supervise's (the main one and the log/ one) that seems tricky to me. And I'd not sure how you'd wait() for the child while still being able to select() on a name pipe in order to read control messages sent by svc. But those details can be worked out, and yes, I'd certainly be willing to lend a hand. The main point is that if such a set of tools were to be made available with a friendly license, would people such as the Apache developers promote them and use them? UNIX needs a standard cross-platform process monitoring solution so individual daemons can stop reinventing the wheel, and the standard control interface will make life easier for sysadmins. -- Jos Backus _/ _/_/_/Santa Clara, CA _/ _/ _/ _/ _/_/_/ _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;