This is to fix PR 15713
suexec-logfile has hardcoded default instead of being
placed in --logfiledir
I'm not sure it's right, though, since I'm not sure of the status of suexec
on win32/other places where ap_config_layout.h isn't available.
-Thom
Index: support/suexec.h
Maybe we should have another directive for the suexec log? But I agree it
shouldn't be hardcoded.
david
- Original Message -
From: Thom May [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, December 31, 2002 11:39 AM
Subject: [PATCH] remove hardcoding of suexec log location
This
* David Reid ([EMAIL PROTECTED]) wrote :
Maybe we should have another directive for the suexec log? But I agree it
shouldn't be hardcoded.
No, we have a --with-suexec-logfile config option, but if that isn't used,
currently the location remains hardcoded. We *should* encourage people to
use
At 05:39 AM 12/31/2002, Thom May wrote:
This is to fix PR 15713
suexec-logfile has hardcoded default instead of being
placed in --logfiledir
I'm not sure it's right, though, since I'm not sure of the status of suexec
on win32/other places where ap_config_layout.h isn't available.
No problem on
Hi,
I have been trying to track down a nasty performance issue with apache
1.3 on linux 2.4.18 (RH7.2). I have narrowed the list down to two
possible culprits (apache or the kernel). I use PHP as well, but I don't
think that is responsible.
The load spikes that occur look like all the processes
I assume you are using the lastest version of 1.3. Try experimenting with the
AcceptMutex config directive and see if selecting different values changes the
behaviour you are seeing.
Bill
Hi,
I have been trying to track down a nasty performance issue with apache
1.3 on linux 2.4.18 (RH7.2).
NetWare doesn't use suexec. To switch users on NetWare, they must be
using our mod_nds (1.3.x) or mod_edir (2.0) module.
Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com
William A. Rowe, Jr. [EMAIL PROTECTED] Tuesday,
I'm working on replacing some mutex locks with atomic-compare-and-swap
based algorithms in the worker MPM, in order to get better concurrency
and lower overhead.
Here's the first change: take the pool recycling code out of the
mutex-protected critical region in the queue_info code. Comments
Oh, I should have mentioned, our mutex issues lessened a lot when we made
more processes with fewer threads each, but that kind of started defeating
the purpose of using the worker mpm after a while... your optimizations
sound like they may help fix this issue.. thanks again.
Dave
-