Re: ap_log_rerror limit size
well, I do not buy the idea of security reasons, but I agree with your last
sentence that they do not see the need to make this a configurable option,
the error log does not need it.
regarding my purpose: mod_dumpio dumps data into the error log file in
chunks, I want to merge them if the message is large and do something with
it before logging. With this limitation, I will need to write it to
somewhere else using my custom file handler.
Vu
On Wed, Mar 13, 2013 at 5:46 PM, wrote:
> On Wed, Mar 13, 2013 at 04:40:50PM +0100, Hoang-Vu Dang wrote:
> > I traced this into the Apache source code (ver 2.4.4). It looks like the
> > error message string is really limited by the size of 8KB.
> >
> > This line is in server/log.c:1097
> >
> > "
> > static void log_error_core(const char *file, int line, int module_index,
> >int level,
> >apr_status_t status, const server_rec *s,
> >const conn_rec *c,
> >const request_rec *r, apr_pool_t *pool,
> >const char *fmt, va_list args)
> > {
> > char errstr[MAX_STRING_LEN];
> > "
> >
> > "
> > And MAX_STRING_LEN is defined in include/httpd.h:298
> >
> > /** The default string length */
> > #define MAX_STRING_LEN HUGE_STRING_LEN
> >
> > /** The length of a Huge string */
> > #define HUGE_STRING_LEN 8192
> > "
> >
> > I tried to increase this value, recompile, and apparently I got a longer
> > message.
> > Please correct me if I am wrong... If this is true then can anyone tell
> me
> > why this "HUGE_STRING_LEN" value is a hard-coded value but not a
> > configurable option ?
>
> I can't speak for the apache core team, but such a limit usually is done
> for security reasons. Tracking buffer overflows in dynamically allocated
> memory can be rather tricky. Btw, what's your goal here? I get the
> feeling that you try to (ab)use the error log as a place to dump large
> blobs of information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace
>
> HTH Ralf Mattes
>
>
> > Cheers, Vu
> that you try to (ab)use the error log as a place to dump large blobs of
> information (traces?). Remember, this is an error log, not a
> place to dump Tolstoy's War and Peace
>
> HTH Ralf Mattes
> >
> >
> > On 03/13/2013 11:16 AM, Eric Covener wrote:
> >> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang
> wrote:
> >>> Hi guys,
> >>>
> >>> Is there any limit of the size of a message log entry? How to control
> >>> this ?
> >>>
> >>> I did this:
> >>>
> >>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
> >>> "%s", buffer);
> >>>
> >>> And the buffer was truncated on the error log. I check the strlen of
> the
> >>> buffer and it was about 320K, and I got only around: ~ 8KB
> >> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
> >> with other entries. Are you sure it's truncated and not just spread
> >> out?
>
Re: ap_log_rerror limit size
On Wed, Mar 13, 2013 at 04:40:50PM +0100, Hoang-Vu Dang wrote:
> I traced this into the Apache source code (ver 2.4.4). It looks like the
> error message string is really limited by the size of 8KB.
>
> This line is in server/log.c:1097
>
> "
> static void log_error_core(const char *file, int line, int module_index,
>int level,
>apr_status_t status, const server_rec *s,
>const conn_rec *c,
>const request_rec *r, apr_pool_t *pool,
>const char *fmt, va_list args)
> {
> char errstr[MAX_STRING_LEN];
> "
>
> "
> And MAX_STRING_LEN is defined in include/httpd.h:298
>
> /** The default string length */
> #define MAX_STRING_LEN HUGE_STRING_LEN
>
> /** The length of a Huge string */
> #define HUGE_STRING_LEN 8192
> "
>
> I tried to increase this value, recompile, and apparently I got a longer
> message.
> Please correct me if I am wrong... If this is true then can anyone tell me
> why this "HUGE_STRING_LEN" value is a hard-coded value but not a
> configurable option ?
I can't speak for the apache core team, but such a limit usually is done
for security reasons. Tracking buffer overflows in dynamically allocated
memory can be rather tricky. Btw, what's your goal here? I get the
feeling that you try to (ab)use the error log as a place to dump large
blobs of information (traces?). Remember, this is an error log, not a
place to dump Tolstoy's War and Peace
HTH Ralf Mattes
> Cheers, Vu
that you try to (ab)use the error log as a place to dump large blobs of
information (traces?). Remember, this is an error log, not a
place to dump Tolstoy's War and Peace
HTH Ralf Mattes
>
>
> On 03/13/2013 11:16 AM, Eric Covener wrote:
>> On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote:
>>> Hi guys,
>>>
>>> Is there any limit of the size of a message log entry? How to control
>>> this ?
>>>
>>> I did this:
>>>
>>> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
>>> "%s", buffer);
>>>
>>> And the buffer was truncated on the error log. I check the strlen of the
>>> buffer and it was about 320K, and I got only around: ~ 8KB
>> If it's more than PIPE_BUF, it won't be atomic and can be interleaved
>> with other entries. Are you sure it's truncated and not just spread
>> out?
Re: ap_log_rerror limit size
I traced this into the Apache source code (ver 2.4.4). It looks like the
error message string is really limited by the size of 8KB.
This line is in server/log.c:1097
"
static void log_error_core(const char *file, int line, int module_index,
int level,
apr_status_t status, const server_rec *s,
const conn_rec *c,
const request_rec *r, apr_pool_t *pool,
const char *fmt, va_list args)
{
char errstr[MAX_STRING_LEN];
"
"
And MAX_STRING_LEN is defined in include/httpd.h:298
/** The default string length */
#define MAX_STRING_LEN HUGE_STRING_LEN
/** The length of a Huge string */
#define HUGE_STRING_LEN 8192
"
I tried to increase this value, recompile, and apparently I got a longer
message.
Please correct me if I am wrong... If this is true then can anyone tell
me why this "HUGE_STRING_LEN" value is a hard-coded value but not a
configurable option ?
Cheers, Vu
On 03/13/2013 11:16 AM, Eric Covener wrote:
On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote:
Hi guys,
Is there any limit of the size of a message log entry? How to control this ?
I did this:
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r,
"%s", buffer);
And the buffer was truncated on the error log. I check the strlen of the buffer
and it was about 320K, and I got only around: ~ 8KB
If it's more than PIPE_BUF, it won't be atomic and can be interleaved
with other entries. Are you sure it's truncated and not just spread
out?
Re: ap_log_rerror limit size
Yes I am sure I can't find other entries related to that request. How to find whether I used PIPE_BUF and how to increase that BUF size ? On Mar 13, 2013, at 11:16 AM, Eric Covener wrote: > On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote: >> Hi guys, >> >> Is there any limit of the size of a message log entry? How to control this ? >> >> I did this: >> >> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, >>"%s", buffer); >> >> And the buffer was truncated on the error log. I check the strlen of the >> buffer and it was about 320K, and I got only around: ~ 8KB > > If it's more than PIPE_BUF, it won't be atomic and can be interleaved > with other entries. Are you sure it's truncated and not just spread > out?
Re: ap_log_rerror limit size
On Wed, Mar 13, 2013 at 6:16 AM, Eric Covener wrote: > On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote: >> Hi guys, >> >> Is there any limit of the size of a message log entry? How to control this ? >> >> I did this: >> >> ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, >> "%s", buffer); >> >> And the buffer was truncated on the error log. I check the strlen of the >> buffer and it was about 320K, and I got only around: ~ 8KB > > If it's more than PIPE_BUF, it won't be atomic and can be interleaved > with other entries. Are you sure it's truncated and not just spread > out? Er if using a piped logger that is.
Re: ap_log_rerror limit size
On Wed, Mar 13, 2013 at 6:01 AM, Hoang Vu Dang wrote: > Hi guys, > > Is there any limit of the size of a message log entry? How to control this ? > > I did this: > > ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, f->r, > "%s", buffer); > > And the buffer was truncated on the error log. I check the strlen of the > buffer and it was about 320K, and I got only around: ~ 8KB If it's more than PIPE_BUF, it won't be atomic and can be interleaved with other entries. Are you sure it's truncated and not just spread out?
