Hey Yann, On Fri, Feb 16, 2018 at 12:56:40PM +0100, Yann Ylavic wrote: > On Fri, Feb 16, 2018 at 12:54 PM, Yann Ylavic <[email protected]> wrote: > > On Fri, Feb 16, 2018 at 11:47 AM, Christian Folini > > <[email protected]> wrote: > >> > >> We have just been told, that a regression affecting several production > >> servers > >> is fixed by > >> http://svn.apache.org/viewvc/httpd/httpd/trunk/server/mpm/event/event.c?r1=1822535&r2=1823047&diff_format=h#l1065 > > > > Are you sure that r1823047 is the commit fixing the issue? > > I would have thought more of r1820796 (already backported to 2.4.30) > > which looks more related to third-party modules. > > Or was it a regression between the two maybe?
Honestly, I can not really tell. It's what the mod_qos dev (in CC) told me. @Pascal can you chime in on that? On Fri, Feb 16, 2018 at 12:54:32PM +0100, Yann Ylavic wrote: > > It's an interaction between mod_qos, mod_reqtimeout and the event mpm that > > led to segfault in our case (triggered by aggressive ssl scanners setting > > off alarms in mod_qos). The qos developers states it's been introduced in > > 2.4.29 and the above patch fixes httpd's part of the problem. He will issue > > a new release as well. > > Do you have more details on the issue and/or relevent commit on the > mod_qos side? There is a very aggressive ssl scanner opening several thousand connections in a few seconds (have not found out which one). mod_qos tries to close the connections, new 2.4 httpd ignores that, then mod_reqtimeout sets in and segfaults. > > So if you could backport this for 2.4.30 or a following release, it would > > be very welcome. > > Real tests and fixes certainly help backports ;) > It would be nice to be sure about the right fix, though. We'd be glad to help. Functioning workaround is in place. Replacing it with a patch httpd in prod is no problem. Cheers, Christian -- No man is more unhappy than he who never faces adversity. For he is not permitted to prove himself. -- Seneca
