| 2015-06-19 16:12:53 |
Branislav Staron |
bug |
|
|
added bug |
| 2015-06-19 16:13:43 |
Branislav Staron |
affects |
installation-report (Ubuntu) |
apache2 (Ubuntu) |
|
| 2015-10-03 08:34:39 |
Stuart Bain |
bug |
|
|
added subscriber Stuart Bain |
| 2015-11-16 08:09:41 |
Henti Smith |
bug watch added |
|
https://bz.apache.org/bugzilla/show_bug.cgi?id=53555 |
|
| 2015-11-16 08:20:23 |
Launchpad Janitor |
apache2 (Ubuntu): status |
New |
Confirmed |
|
| 2016-11-24 15:10:54 |
Stewart Campbell |
bug |
|
|
added subscriber Stewart Campbell |
| 2016-11-28 08:09:54 |
Christian Ehrhardt |
bug |
|
|
added subscriber Ubuntu Server Team |
| 2016-11-28 08:10:28 |
Christian Ehrhardt |
apache2 (Ubuntu): status |
Confirmed |
Triaged |
|
| 2016-11-28 08:10:31 |
Christian Ehrhardt |
apache2 (Ubuntu): importance |
Undecided |
Medium |
|
| 2016-12-12 14:00:22 |
Robie Basak |
tags |
|
server-next |
|
| 2016-12-21 08:08:20 |
Rolf Timmermans |
bug |
|
|
added subscriber Rolf Timmermans |
| 2017-02-22 00:37:32 |
Launchpad Janitor |
apache2 (Ubuntu): status |
Triaged |
Fix Released |
|
| 2017-07-07 11:49:59 |
Junien F |
bug |
|
|
added subscriber Junien Fridrick |
| 2017-07-07 11:50:06 |
Junien F |
bug |
|
|
added subscriber The Canonical Sysadmins |
| 2017-07-07 12:00:46 |
Haw Loeung |
bug |
|
|
added subscriber Haw Loeung |
| 2017-07-10 07:00:36 |
Haw Loeung |
nominated for series |
|
Ubuntu Xenial |
|
| 2017-07-10 07:00:36 |
Haw Loeung |
bug task added |
|
apache2 (Ubuntu Xenial) |
|
| 2017-07-10 07:00:36 |
Haw Loeung |
nominated for series |
|
Ubuntu Trusty |
|
| 2017-07-10 07:00:36 |
Haw Loeung |
bug task added |
|
apache2 (Ubuntu Trusty) |
|
| 2017-07-10 07:02:27 |
Haw Loeung |
apache2 (Ubuntu Xenial): status |
New |
Confirmed |
|
| 2017-07-10 07:02:32 |
Haw Loeung |
apache2 (Ubuntu Trusty): status |
New |
Confirmed |
|
| 2017-07-10 07:18:20 |
Haw Loeung |
nominated for series |
|
Ubuntu Zesty |
|
| 2017-07-10 07:18:20 |
Haw Loeung |
bug task added |
|
apache2 (Ubuntu Zesty) |
|
| 2017-07-10 07:18:48 |
Haw Loeung |
apache2 (Ubuntu Zesty): status |
New |
Fix Released |
|
| 2017-08-17 17:41:06 |
J.K.Button |
bug |
|
|
added subscriber J.K.Button |
| 2017-11-06 18:06:14 |
Felipe Reyes |
bug |
|
|
added subscriber Felipe Reyes |
| 2017-11-14 14:25:02 |
Christian Ehrhardt |
bug |
|
|
added subscriber ChristianEhrhardt |
| 2017-11-14 14:25:08 |
Christian Ehrhardt |
apache2 (Ubuntu Xenial): status |
Confirmed |
Triaged |
|
| 2017-11-15 09:31:53 |
Christian Ehrhardt |
apache2 (Ubuntu Xenial): status |
Triaged |
Incomplete |
|
| 2017-11-15 09:31:55 |
Christian Ehrhardt |
apache2 (Ubuntu Trusty): status |
Confirmed |
Incomplete |
|
| 2018-02-26 13:19:13 |
Christian Ehrhardt |
apache2 (Ubuntu Trusty): status |
Incomplete |
Won't Fix |
|
| 2018-02-26 13:31:04 |
Christian Ehrhardt |
description |
On the clean install Ubuntu 14.04 with Apache without almost any client load the Apache server with the command "service apache2 reload" itself allocates slots marked with "Gracefully finishing" for which rejects new connections.
For full rejection of new requests is sufficient to perform 4x command "service apache2 reload".
Ubuntu 14.04.2 LTS
Apache 2.4.7-ubuntu4.4 (mpm_event)
Kernel 2.16.0-30-generic
Reproduce problem:
#################################################
1/ service apache2 start
______________________________________________________W_________
___________.....................................................
......................
2/ service apache2 reload
.........................GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________W__
______________________
3/ service apache2 reload
___W_____________________GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________...
......................
4/ service apache2 reload
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG___
W_____________________
5/ service apache2 reload -> Server Apache not responding
With logs in apache error log file:
... [mpm_event:error] [pid 9381:tid 1234563234] AH00485: scoreboard is full, not at MaxRequestWorkers
...
#################################################
My workaround was change to MPM module from "mpm_event" to "mpm_worker". |
[Impact]
* apache2 reload can fill up the scorecard with graceful reastarting
workers to an amount that it is unable to serve more requests.
* Backport fix from upstream to avoid the issue
[Test Case]
* In commend #8 I outlined some steps to fill up the scorecard with
Gracefully stopping processes. But that never triggered the reported
bug of eventually breaking new requests for me (It is still good to
verify some busy tests on this part of the apache code)
-> Therefore one of the reporters of the bug tested the ppa quite a
while on his main machines that formerly were affected by the issue.
-> no clear "do this then X happens" test case steps
[Regression Potential]
* It is a rather complex code change in the mpm event handling.
Only the first change is to code, the other two are for the
documentation to match.
We tested some apache benchmarks to check the effect, but found neither
a positive nor negative impact in general (other than the bug being
resolved). Yet if people rely on very specific behavior of the mpm
handling that might change a bit.
It will change for the good of it, but always remember xkcd.com/1172
TL;DR: IMHO it clearly has a ">none" regression potential on the mpm
event handling
[Other Info]
* Since this is hard to test we had a 2+ week test on the ppa, see
comments c#8 - c#15
* It clearly is a fix for some (e.g. the reporter of the bug), but I'd
understand if the SRU Team would rate it as feature and deny it for an
SRU - depends on the POV, certainly worth to be reviewed at least.
----
On the clean install Ubuntu 14.04 with Apache without almost any client load the Apache server with the command "service apache2 reload" itself allocates slots marked with "Gracefully finishing" for which rejects new connections.
For full rejection of new requests is sufficient to perform 4x command "service apache2 reload".
Ubuntu 14.04.2 LTS
Apache 2.4.7-ubuntu4.4 (mpm_event)
Kernel 2.16.0-30-generic
Reproduce problem:
#################################################
1/ service apache2 start
______________________________________________________W_________
___________.....................................................
......................
2/ service apache2 reload
.........................GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________W__
______________________
3/ service apache2 reload
___W_____________________GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________...
......................
4/ service apache2 reload
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG___
W_____________________
5/ service apache2 reload -> Server Apache not responding
With logs in apache error log file:
... [mpm_event:error] [pid 9381:tid 1234563234] AH00485: scoreboard is full, not at MaxRequestWorkers
...
#################################################
My workaround was change to MPM module from "mpm_event" to "mpm_worker". |
|
| 2018-02-26 13:31:09 |
Christian Ehrhardt |
apache2 (Ubuntu Xenial): status |
Incomplete |
In Progress |
|
| 2018-03-22 15:18:32 |
Łukasz Zemczak |
description |
[Impact]
* apache2 reload can fill up the scorecard with graceful reastarting
workers to an amount that it is unable to serve more requests.
* Backport fix from upstream to avoid the issue
[Test Case]
* In commend #8 I outlined some steps to fill up the scorecard with
Gracefully stopping processes. But that never triggered the reported
bug of eventually breaking new requests for me (It is still good to
verify some busy tests on this part of the apache code)
-> Therefore one of the reporters of the bug tested the ppa quite a
while on his main machines that formerly were affected by the issue.
-> no clear "do this then X happens" test case steps
[Regression Potential]
* It is a rather complex code change in the mpm event handling.
Only the first change is to code, the other two are for the
documentation to match.
We tested some apache benchmarks to check the effect, but found neither
a positive nor negative impact in general (other than the bug being
resolved). Yet if people rely on very specific behavior of the mpm
handling that might change a bit.
It will change for the good of it, but always remember xkcd.com/1172
TL;DR: IMHO it clearly has a ">none" regression potential on the mpm
event handling
[Other Info]
* Since this is hard to test we had a 2+ week test on the ppa, see
comments c#8 - c#15
* It clearly is a fix for some (e.g. the reporter of the bug), but I'd
understand if the SRU Team would rate it as feature and deny it for an
SRU - depends on the POV, certainly worth to be reviewed at least.
----
On the clean install Ubuntu 14.04 with Apache without almost any client load the Apache server with the command "service apache2 reload" itself allocates slots marked with "Gracefully finishing" for which rejects new connections.
For full rejection of new requests is sufficient to perform 4x command "service apache2 reload".
Ubuntu 14.04.2 LTS
Apache 2.4.7-ubuntu4.4 (mpm_event)
Kernel 2.16.0-30-generic
Reproduce problem:
#################################################
1/ service apache2 start
______________________________________________________W_________
___________.....................................................
......................
2/ service apache2 reload
.........................GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________W__
______________________
3/ service apache2 reload
___W_____________________GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________...
......................
4/ service apache2 reload
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG___
W_____________________
5/ service apache2 reload -> Server Apache not responding
With logs in apache error log file:
... [mpm_event:error] [pid 9381:tid 1234563234] AH00485: scoreboard is full, not at MaxRequestWorkers
...
#################################################
My workaround was change to MPM module from "mpm_event" to "mpm_worker". |
[Impact]
* apache2 reload can fill up the scorecard with graceful reastarting
workers to an amount that it is unable to serve more requests.
* Backport fix from upstream to avoid the issue
[Test Case]
* In comment #8 I outlined some steps to fill up the scorecard with
Gracefully stopping processes. But that never triggered the reported
bug of eventually breaking new requests for me (It is still good to
verify some busy tests on this part of the apache code)
-> Therefore one of the reporters of the bug tested the ppa quite a
while on his main machines that formerly were affected by the issue.
-> no clear "do this then X happens" test case steps
* Perform arbitrary additional functional tests on the package to make sure no regressions are visible
[Regression Potential]
* It is a rather complex code change in the mpm event handling.
Only the first change is to code, the other two are for the
documentation to match.
We tested some apache benchmarks to check the effect, but found neither
a positive nor negative impact in general (other than the bug being
resolved). Yet if people rely on very specific behavior of the mpm
handling that might change a bit.
It will change for the good of it, but always remember xkcd.com/1172
TL;DR: IMHO it clearly has a ">none" regression potential on the mpm
event handling
[Other Info]
* Since this is hard to test we had a 2+ week test on the ppa, see
comments c#8 - c#15
* It clearly is a fix for some (e.g. the reporter of the bug), but I'd
understand if the SRU Team would rate it as feature and deny it for an
SRU - depends on the POV, certainly worth to be reviewed at least.
----
On the clean install Ubuntu 14.04 with Apache without almost any client load the Apache server with the command "service apache2 reload" itself allocates slots marked with "Gracefully finishing" for which rejects new connections.
For full rejection of new requests is sufficient to perform 4x command "service apache2 reload".
Ubuntu 14.04.2 LTS
Apache 2.4.7-ubuntu4.4 (mpm_event)
Kernel 2.16.0-30-generic
Reproduce problem:
#################################################
1/ service apache2 start
______________________________________________________W_________
___________.....................................................
......................
2/ service apache2 reload
.........................GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________W__
______________________
3/ service apache2 reload
___W_____________________GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGG__________________________________________________...
......................
4/ service apache2 reload
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG___
W_____________________
5/ service apache2 reload -> Server Apache not responding
With logs in apache error log file:
... [mpm_event:error] [pid 9381:tid 1234563234] AH00485: scoreboard is full, not at MaxRequestWorkers
...
#################################################
My workaround was change to MPM module from "mpm_event" to "mpm_worker". |
|
| 2018-03-22 15:21:33 |
Łukasz Zemczak |
apache2 (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2018-03-22 15:21:35 |
Łukasz Zemczak |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-03-22 15:21:36 |
Łukasz Zemczak |
bug |
|
|
added subscriber SRU Verification |
| 2018-03-22 15:21:41 |
Łukasz Zemczak |
tags |
server-next |
server-next verification-needed verification-needed-xenial |
|
| 2018-03-26 07:18:56 |
Robie Basak |
bug |
|
|
added subscriber Robie Basak |
| 2018-03-27 04:23:57 |
Haw Loeung |
tags |
server-next verification-needed verification-needed-xenial |
server-next verification-failed verification-failed-xenial |
|
| 2018-04-04 05:03:34 |
Christian Ehrhardt |
apache2 (Ubuntu Xenial): status |
Fix Committed |
Triaged |
|
| 2020-06-24 15:13:32 |
Christian Ehrhardt |
tags |
server-next verification-failed verification-failed-xenial |
verification-failed verification-failed-xenial |
|
| 2022-02-10 20:42:20 |
Sergio Durigan Junior |
apache2 (Ubuntu Xenial): status |
Triaged |
Won't Fix |
|
