Activity log for bug #1466926

Date Who What changed Old value New value Message
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 Fridrick bug added subscriber Junien Fridrick
2017-07-07 11:50:06 Junien Fridrick 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