22.01.2010 15:28, Akins, Brian ???(??):
Each process (not thread) has an open filehandle with mod_log_config,
correct?
Having almost finished the necessary changes to mod_log_config, I
realized, that there are/may be modules, that keep their own logging.
Being able to include those in m
On 22 Jan 2010, at 10:28 PM, Akins, Brian wrote:
Trying to signal all the processes, all the threads, and all the
event
loops to close and reopen a file simultaneously simply isn't
feasible or
accurate enough to be useful.
Each process (not thread) has an open filehandle with mod_log_confi
On 22 Jan 2010, at 10:26 PM, Akins, Brian wrote:
What you're probably after are piped logs:
The amount of context switches this can create is almost mind
boggling...
My experience with this has been on multiprocessor RHEL machines, the
cost of piped logging in our case was minimal.
If
On Jan 22, 2010, at 3:15 PM, Mikhail Teterin wrote:
> 22.01.2010 14:50, Brian J. France ???(??):
>> I was going to bring up the patch during the Monday/Tuesday hack days along
>> with a few others.
>>
> Can you send me the patch directly /today/? Thanks!
Here is the patch:
http://www.b
22.01.2010 15:28, Akins, Brian ???(??):
Each process (not thread) has an open filehandle with mod_log_config,
correct?
Except for the ErrorLog... Perhaps, that handle is reachable from a
module somehow too?
-mi
On 1/22/10 2:39 PM, "Graham Leggett" wrote:
> Trying to signal all the processes, all the threads, and all the event
> loops to close and reopen a file simultaneously simply isn't feasible or
> accurate enough to be useful.
Each process (not thread) has an open filehandle with mod_log_config,
co
On 1/22/10 2:18 PM, "Graham Leggett" wrote:
> What you're probably after are piped logs:
The amount of context switches this can create is almost mind boggling...
--
Brian Akins
22.01.2010 14:50, Brian J. France написав(ла):
Funny you should bring this up, at work we have been look at out patches to apr
and httpd that we can give back to the up stream public source and one of those
patches is to apr to allow hupless log rotation in httpd 2.x.
The patch adds APR_FOPEN_
On Jan 22, 2010, at 1:43 PM, Mikhail T. wrote:
> Hello!
>
> Some of our web-servers take a while to restart (because some custom
> modules need to login to database backends, etc.) This makes it
> undesirable for us to use the SIGUSR1 (for graceful restart) and we
> currently log to stdin of an ea
2010/1/22 Mikhail T. :
> 22.01.2010 14:33, Jeff Trawick написав(ла):
>>
>> the open_logs hook runs only in the parent
>
> I see... And the children simply inherit it after forks?
yes
On 2010/01/22 9:24 PM, Mikhail T. wrote:
> Thanks for the pointer, sir. We are using cronolog now. But it is, quite
> obviously, a hack -- a work-around for Apache's inability to handle
> log-rotation on its own.
It is not a hack.
Apache httpd isn't a single process, but rather many potential
pr
22.01.2010 14:33, Jeff Trawick написав(ла):
the open_logs hook runs only in the parent
I see... And the children simply inherit it after forks? Thank you,
-mi
2010/1/22 Mikhail T. :
> 22.01.2010 14:03, Jeff Trawick написав(ла):
>>>
>>> > Currently there are ap_run_open_logs and worker_open_logs. Can my
>>> > hypothetical signal-handler simply go through the list of opened
>>> > descriptors, set them to new values and close the old?
>>>
>>
>> You'd nee
22.01.2010 14:18, Graham Leggett написав(ла):
What you're probably after are piped logs:
http://httpd.apache.org/docs/2.2/logs.html#piped
If you pipe the log to something like cronolog, cronolog is able to
rotate logs for you without needing to restart httpd.
Thanks for the pointer, sir. We a
On 22 Jan 2010, at 8:43 PM, Mikhail T. wrote:
Some of our web-servers take a while to restart (because some custom
modules need to login to database backends, etc.) This makes it
undesirable for us to use the SIGUSR1 (for graceful restart) and we
currently log to stdin of an easier to restart co
22.01.2010 14:03, Jeff Trawick написав(ла):
> Currently there are ap_run_open_logs and worker_open_logs. Can my
> hypothetical signal-handler simply go through the list of opened
> descriptors, set them to new values and close the old?
You'd need to do that in every child process, witho
On Fri, Jan 22, 2010 at 1:43 PM, Mikhail T. wrote:
> Hello!
>
> Some of our web-servers take a while to restart (because some custom
> modules need to login to database backends, etc.) This makes it
> undesirable for us to use the SIGUSR1 (for graceful restart) and we
> currently log to stdin of a
Hello!
Some of our web-servers take a while to restart (because some custom
modules need to login to database backends, etc.) This makes it
undesirable for us to use the SIGUSR1 (for graceful restart) and we
currently log to stdin of an easier to restart command-line utility.
How hard would it b
18 matches
Mail list logo
