Bug 56832 - mod_ratelimit error brigade pass failed
Summary: mod_ratelimit error brigade pass failed
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ratelimit (show other bugs)
Version: 2.4.10
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: FixedInTrunk
Depends on:
Reported: 2014-08-09 21:01 UTC by Tomas M
Modified: 2015-01-23 10:19 UTC (History)
1 user (show)

Modify log level of errors so they are no longer reported in error_log (1.93 KB, patch)
2014-08-18 08:22 UTC, Tomas M
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas M 2014-08-09 21:01:32 UTC
I'm running apache with mod_ratelimit, using the following in config file:
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 0

This way I activate Rate-Limit output filter but disable it by setting rate-limit env variable to 0, so all downloads go in full speed. When any particular file is to be sent in a slower manner, a php scripts sets apache_setenv("rate-limit",30) in order to activate the rate limit.

Sometimes I notice in apache log the following line:
[Sat Aug 09 08:20:02.914169 2014] [ratelimit:error] [pid 10795] [client XXXXX:51962] AH01457: rl: brigade pass failed., referer: XXXX

I've reviewed the source code and I tried to understand how brigades work.
The error message comes from mod_ratelimit.c, when return value of ap_pass_brigade() is not equal to APR_SUCCESS.

First of all I would like to better understand what happens. Do I understand it right that once the break is called, so it looks like the file is sent in full speed, right? Does it interrupt the connection or download?

Is the error "recoverable", I mean, is the user still getting the file he tries to download? If not, can we make some code adjustments in order to try to "fix" the problem on the fly, eg. by retrying ap_pass_brigade() call? If the error is recoverable, can we silence the error message?

Thank you
Comment 1 Eric Covener 2014-08-09 21:13:50 UTC
I notice this message does not pass "rv". You might want to rebuild with it adde and also log %X and trace1 logging and see if these are just occasional routine client disconnects

But more importantly, I think the severity of ERROR is too high. 9 times out of 10 it's going to mean the core output filter couldn't write out to the client (this will occasionally happen when a client disconnects. That error is logged at INFO in 2.2 and trace1 in 2.4/trunk.

If you find a bug, feel free to re-open -- but for discussion, please use users@httpd.apache.org rather than the bug reporting database.
Comment 2 Eric Covener 2014-08-09 21:16:15 UTC
On second thought, repurposing this bug to remove those messages from mod_ratelimit. Most other filters simply do not bother logging an error received in ap_pass_brigade much less at ERRROR level.
Comment 3 Tomas M 2014-08-10 06:27:43 UTC
I was able to track down that the error message in apache log appears if the client forcibly disconnects. So it is not that the message would cause disconnect, but contrary the disconnection of client causes the error message.

I think this shouldn't be logged.
Comment 4 Tomas M 2014-08-18 08:22:28 UTC
Created attachment 31926 [details]
Modify log level of errors so they are no longer reported in error_log

I am proposing a patch for mod_ratelimit.
It modifies the error messages level to APLOG_TRACE1.
I have no deep understanding of logging in Apache but I assume that once the errors are marked as trace1, it won't fill up apaches error_log file any more.

If I am wrong, feel free to modify it in any other way to silence the error messages, they are useless anyway! I don't really want to see in error_log all users who disconnected the connection and so on.

Please consider this patch for httpd 2.4.11 !

Thank you
Comment 5 Eric Covener 2014-08-19 15:45:13 UTC
this was fixed in trunk last week and is proposed for 2.4.x backport


I only modified the pass_brigade messages, because those will have already been reported.
Comment 6 Yann Ylavic 2015-01-23 10:19:46 UTC
Backported to 2.4.11 in r1622708.