Re: The use of CORE_PRIVATE
On Fri, 2005-02-11 at 01:34 -0800, Greg Stein wrote: > Um... no. Why would somebody need to do that? In my experience, you might > run a sub-request. But you do *not* construct request_rec objects out of > the blue. Unless one wants to run a "canned" sub-request (through the use of some other functions), this function (and some others) is required for sub- requests as well. If "canned" sub-request functions are used, "custom" sub-request functionality is difficult to achieve without not so nice workarounds. I'm not sure why constructing a request would be so unusual. Application servers running inside Apache may need to do this stuff all the time. > Can you explain your use case? Why do you need that function? The new request hits an authentication URI, thus authenticating the user without the need to supply authentication headers (of basic authentication) on every request (in fact - ever). The result of authentication is stored in the application's session store for further use. I can see instances where one would run a request internally, get the result and include (parts of it) in the response. > I've said before: mod_perl is a poor example. It is too invasive with our > APIs. And if it is referring to one of those functions via defining > CORE_PRIVATE, then it rightly deserves a thrashing. OK, maybe. But there are plenty of other modules inside Apache distro itself that use CORE_PRIVATE stuff too. This comes to my original question - what is really considered "public API"? -- Bojan
Re: [PATCH] Win32: install service in rewrite args rather than post_config?
Jeff White wrote: From: "Bill Stoddard" It would, but is it worth the extra code to enable switching between both behaviours? Got some code to review? Bill What's the "real problem" Bill (Stoddard) wants to over come or what does he "really" want to happen? That's almost haiku :) Bill R correctly identified the reason I'd like to see the service install occur before post-config. If the last thing your installer does is install the service, the service install will fail if there is a problem with httpd.conf. The most likely problem is that some other service is using port 80 (or port 443, or whatever port you want httpd to listen on). Bill
[1.3] (not) stripping httpd 1.3 binary on Darwin
Dear Dev folks, This weekend I felt the need to gdb step through an httpd 1.3 build on my Powerbook. Imagine my surprise when the installed httpd, built with CFLAGS="-DDEBUG -g -O0", was devoid of symbols. A little investigation led me to the fact that the configure script has a special case for Darwin that causes the install.sh to strip the installed core binaries, regardless of any --without-execstrip flags to configure. No other platform does this. I wonder whether this may be in the tree because Apple doesn't want to ship unstripped binaries? Wsanchez? Anyway, the expected behaviour would be to install unstripped binaries of everything when the --without-execstrip flag is given. The following patch fixes that by applying the same logic to iflags_core and iflags_dso that is already applied to iflags_programs (which directs installing the support binaries): Index: configure === --- configure (revision 153561) +++ configure (working copy) @@ -927,6 +927,8 @@ ;; --without-execstrip) iflags_program=`echo "$iflags_program" | sed -e 's/-s//'` +iflags_core=`echo "$iflags_core" | sed -e 's/-S//' -e 's/\"-S\"//'` +iflags_dso=`echo "$iflags_dso" | sed -e 's/-S//' -e 's/\"-S\"//'` ;; --suexec-caller=*) suexec_caller="$apc_optarg" This does the trick for me, and should be a noop on most platforms. Note that on no other platform do we install a stripped httpd: the --without-execstrip only has effect on the support binaries. Is this what we want? S. -- [EMAIL PROTECTED] http://www.temme.net/sander/ PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF configure_1_3.patch Description: Binary data smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Win32: install service in rewrite args rather than post_config?
From: "Bill Stoddard" It would, but is it worth the extra code to enable switching between both behaviours? Got some code to review? Bill What's the "real problem" Bill (Stoddard) wants to over come or what does he "really" want to happen? Got some example ideas? Jeff
Re: Terminating cgi scripts
On Thu, 10 Feb 2005 18:09:46 +0530, Kiran Mendonce <[EMAIL PROTECTED]> wrote:
> We had a customer scenario (on HP-UX) recently where cgi scripts that
> were spawned by mod_cgid continued to run even when httpd was stopped.
> The ppid of these scripts was automatically 1 when the httpd processes
> terminated. The customer does not find any reason why these processes
> need to continue to run especially since the scripts need to be run
> again when httpd restarts. This does seem like a reasonable demand.
certainly
>
> The problem occurs both with mod_cgi and mod_cgid. Being a novice, I
> have the following questions. It would be really helpful to get your
> take on the following :
> 1. How do I get all the child pids spawned by the cgid daemon and the
> httpd child (mod_cgi) so I can kill them when I get a signal ? Is it
> okay if I modify apachectl so that I can get all the processes that are
> owned by 'www' and still running using the 'ps' command and then kill
> them after "httpd -k stop" ?
I wouldn't pursue that unless there is absolutely no practical way to
fix the code. In the worst case, can't the MPM figure out right
before exiting that it is the parent of some active processes, and
continuing to exit will keep them stranded? But I'd suggest pursuing
the mod_cgid issues first.
> 2. If that is not acceptable, I would need to change the code. I looked
> at the mod_cgid sources and I found that the pids of all the processes
> that cgid spawns are hashed in the hash table script_hash. If I could
> make script_hash a static global variable, I could get the pids in the
> signal handler and kill the processes. I have changed the code and it is
> working. Would I be breaking something ?
If the cgid daemon is about to exit, it is reasonable for it to wipe
out any processes it has created and which are still active. But do
as little as possible in a signal handler (i.e., avoid adding any
logic there). When the existing signal hander is called, it sets a
flag which causes the mainline logic to exit. You should see mod_cgid
exiting the loop "while (!daemon_should_exit) {", and while still in
that function you have addressibility to the hash table.
> 3. We use the worker MPM. For mod_cgi, I would need to make changes in
> worker.c since there is no daemon here.
It is a bad thing if worker.c has logic specific to CGIs. Also, it is
invalid to use mod_cgi with a threaded MPM on Unix. Maybe it will
seem to work, but bad things can happen under heavy load, with
descriptors getting inherited by the wrong child processes.
> In mod_cgi code, I find that
> everytime a process is spawned, apr_pool_note_subprocess() is called.
On Unix, mod_cgi should only be used with a non-threaded MPM. And
that non-threaded MPM (prefork) child process will not exit* without
cleaning up the pool that the processes have been associated with.
*if something is stalling and keeping the child process from exiting
in a timely manner, the Apache parent will kill the child process,
such that this cleanup will not be performed.
