Hi list,
i like mod fcgid a lot but there's one bug which makes me crazy.
On DSO unload (Apache reload ) all child's get killed no matter if they process
requests or not. This makes no sense to me httpd processes itself are also kept
until all requests are served.
Stefan
Excuse my typo sent f
Thanks!
A simple test script I've used is
print header;
print content1;
sleep 30;
print content2;
Stefan
Excuse my typo sent from my mobile phone.
> Am 22.08.2016 um 18:07 schrieb Stefan Eissing :
>
> Hi Stefan,
>
> I am looking into this. It is definitely a bug in mod_http2.
>
>> Am 21.08.
Hi Stefan,
were you able to reproduce? Did you need any help?
Greets,
Stefan
Am 22.08.2016 um 18:07 schrieb Stefan Eissing:
> Hi Stefan,
>
> I am looking into this. It is definitely a bug in mod_http2.
>
>> Am 21.08.2016 um 14:26 schrieb Stefan Priebe :
>>
>> Hi,
>>
>> i'm running apache 2.4.23
4.08.2016 um 10:18 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Stefan,
>>
>> were you able to reproduce? Did you need any help?
>>
>> Greets,
>> Stefan
>> Am 22.08.2016 um 18:07 schrieb Stefan Eissing:
>>> Hi Stefan,
>>>
>
palive) --> [IDLE]
Greets,
Stefan
Am 25.08.2016 um 10:26 schrieb Stefan Eissing:
> So, the fix is in both trunk and 2.4.x and the github repo has a new release.
> Can you verify that it works for you also? Thanks!
>
>
>> Am 24.08.2016 um 10:18 schrieb Stefan Priebe - Profihos
Am 29.08.2016 um 15:31 schrieb Stefan Eissing:
>
>> Am 26.08.2016 um 20:02 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> [Fri Aug 26 19:54:05.321979 2016] [http2:debug] [pid 13222:tid
>> 139700320794368] h2_stream.c(205): [client 1.2.3.4:38822] AH03082:
>>
Am 29.08.2016 um 15:52 schrieb Stefan Eissing:
>
>> Am 29.08.2016 um 15:43 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Am 29.08.2016 um 15:31 schrieb Stefan Eissing:
>>>
>>>> Am 26.08.2016 um 20:02 schrieb Stefan Priebe - Profihost AG
&
ng a (part of
> a) response. How that is tied to closing stderr or not, I have not the
> slightest idea. Can you send me your cgi/perl related config, so I might do
> some tests on my own? thanks!
>
>
>> Am 29.08.2016 um 16:16 schrieb Stefan Priebe - Profihost AG
>>
Thanks a lot! That was the issue. So it seems it's just easier to
trigger with http/2.
Greets,
Stefan
Am 01.09.2016 um 14:45 schrieb Eric Covener:
> On Wed, Aug 31, 2016 at 7:37 AM, Stefan Eissing
> wrote:
>> It really looks as if the CGI process simply died without sending a (part of
>> a) res
Hi,
Am 15.09.2016 um 11:20 schrieb Stefan Eissing:
> The patch works nicely on my OS X workhorse. Without it, I see 5-15
> reactivations of the child processes every second, with the patch it stays at
> 0 most of the time.
>
> Very nice work, Yann!
that sounds great. Is there a version availab
Hi Luca,
Am 18.09.2016 um 12:16 schrieb Luca Toscano:
> Hi Stefan,
>
> 2016-09-15 11:41 GMT+02:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> Hi,
>
> Am 15.09.2016 um 11:20 schrieb Stefan Eissing:
> > The patch works nicely
Hi Yann,
Am 18.09.2016 um 14:16 schrieb Yann Ylavic:
> On Sun, Sep 18, 2016 at 12:16 PM, Luca Toscano wrote:
>>
>> 2016-09-15 11:41 GMT+02:00 Stefan Priebe - Profihost AG
>> :
>>>
>>> that sounds great. Is there a version available that applies to 2.4 ?
>
ote:
>>
>> 2016-09-15 11:41 GMT+02:00 Stefan Priebe - Profihost AG
>> :
>>>
>>> that sounds great. Is there a version available that applies to 2.4 ?
>>
>> I tried to study/port Yann's patch to 2.4.x. but it is not that
>> straightforward si
Hi Luca,
Am 23.09.2016 um 13:47 schrieb Luca Toscano:
> Hi Stefan,
>
> 2016-09-23 13:15 GMT+02:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> Hi Yann,
>
> a applied the latest patch (incl. fudge factor) to 1500 real life
>
Thanks Yann. I'll wait a few days to check first if i'll see this on
other hosts too. i'll also try to grab the server-status but i'm not
sure if the server will answer to this request if the scoreboard is full.
Greets,
Stefan
Am 23.09.2016 um 16:53 schrieb Yann Ylavic:
> With the patch this time
Hi Yann,
Hi Luca,
right now i had another server which shows:
AH00485: scoreboard is full, not at MaxRequestWorkers msg.
I never saw that before applying the event patch.
A fullstatus view is not answered - so the whole apache hangs. Also it
has 84 running processes instead of normally just 4-
Hi,
saw v5 attached to bugzilla. Which one should I take?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
> Am 24.09.2016 um 15:05 schrieb Yann Ylavic :
>
> Hi Stefan,
>
> thanks again for the tests and very useful feedbacks!
>
> On Fri, Sep 23, 2016 at 9
currently no deadlocks since V5 also no old httpd processes anymore.
Stefan
Am 24.09.2016 um 17:32 schrieb Yann Ylavic:
> On Sat, Sep 24, 2016 at 5:13 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> saw v5 attached to bugzilla. Which one should I take?
>
> Either, v5 is
Am 05.10.2016 um 12:50 schrieb Luca Toscano:
> Hi Stefan,
>
> 2016-09-26 14:26 GMT+02:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> currently no deadlocks since V5 also no old httpd processes anymore.
>
>
> if you still have patienc
Hi Luca,
Am 10.10.2016 um 16:48 schrieb Luca Toscano:
> Hi Stefan,
>
> 2016-10-07 10:11 GMT+02:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> Am 05.10.2016 um 12:50 schrieb Luca Toscano:
> > Hi Stefan,
> >
> >
Hi Yann,
here is a follow up on this old thread with some problems again. See below.
Am 23.09.2016 um 21:26 schrieb Stefan Priebe - Profihost AG:
> Hi Yann,
> Hi Luca,
>
> right now i had another server which shows:
> AH00485: scoreboard is full, not at MaxRequestWorkers msg.
&
Am 23.12.2016 um 01:41 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Tue, Dec 20, 2016 at 1:52 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> Today i had another server giving no answers to any requests. apache
>> fullstatus did not respond.
>
> Since v5 of th
faults.
>
> exit signal Segmentation
>
> server-error.log:
> AH00052: child pid 14110 exit signal Segmentation fault (11)
>
> currently i'm trying to grab a core dump.
>
> Greets,
> Stefan
>
> Am 26.12.2016 um 21:18 schrieb Stefan Priebe - Profihost
Hi,
site is mostly used with http2. So it may be totally unrelated to
mod_http2. Sorry for the noise than. I just thought it by digging
through the traces.
Stefan
Am 18.01.2017 um 12:34 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Wed, Jan 18, 2017 at 11:33 AM, Stefan Priebe - Pro
Am 18.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> site is mostly used with http2. So it may be totally unrelated to
> mod_http2. Sorry for the noise than. I just thought it by digging
> through the traces.
>
> Stefan
>
> Am 18.01.2017 um 12:34
Hi Yann,
is it enought to revert that commit?
http://svn.apache.org/r1762701
Stefan
Am 18.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> site is mostly used with http2. So it may be totally unrelated to
> mod_http2. Sorry for the noise than. I just thought i
Ok will wait whether you provide a fix or I should revert that part.
Stefan
Excuse my typo sent from my mobile phone.
> Am 18.01.2017 um 16:32 schrieb Yann Ylavic :
>
> On Wed, Jan 18, 2017 at 4:17 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> is it enought to re
at 4:38 PM, Stefan Priebe - Profihost AG
> wrote:
>> Ok will wait whether you provide a fix or I should revert that part.
>
> Patch updated in PR 57399.
>
> Thanks,
> Yann.
>
I also tried to remove rev 1762701 from the v6 patchset. But it does not
match.
Stefan
Am 18.01.2017 um 22:23 schrieb Stefan Priebe - Profihost AG:
> Hi Yann,
>
> sadly it does not solve the issue.
>
> Trace looks still the same:
> Core was generated by `/usr/local/apache2/
Am 18.01.2017 um 22:44 schrieb Yann Ylavic:
> On Wed, Jan 18, 2017 at 10:23 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> sadly it does not solve the issue.
>
> OK, thanks, back to the paper.
>
> Any [error] log maybe?
What kind of? server-error.log just says
[W
Am 18.01.2017 um 22:50 schrieb Yann Ylavic:
> On Wed, Jan 18, 2017 at 10:44 PM, Yann Ylavic wrote:
>> On Wed, Jan 18, 2017 at 10:23 PM, Stefan Priebe - Profihost AG
>> wrote:
>>>
>>
>> Also, do you confirm that:
>> 1. it didn't crash with v5 +
Am 18.01.2017 um 22:53 schrieb Yann Ylavic:
> On Wed, Jan 18, 2017 at 10:50 PM, Yann Ylavic wrote:
>> On Wed, Jan 18, 2017 at 10:44 PM, Yann Ylavic wrote:
>>> On Wed, Jan 18, 2017 at 10:23 PM, Stefan Priebe - Profihost AG
>>> wrote:
>>>>
>>>
>&
27;s a regression in 2.4.25 itself or in mod_http2.
Stefan
Am 19.01.2017 um 00:52 schrieb Yann Ylavic:
> On Wed, Jan 18, 2017 at 10:49 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> v5 does not apply to 2.4.25. If you can send me a v5 version that
>> applies to 2.4.25 i
with
core mod_http2 and mod_http2 v1.8.8.
Is a regression in mod_http2 possible?
Greets,
Stefan
Am 19.01.2017 um 07:55 schrieb Stefan Priebe - Profihost AG:
> Dear Stefan,
> dear Yann,
>
> a longer test run shows it's also crashing without any mpm_event patch
> at all. So I&
x7f54ef00e9a8 in ?? ()
>> #6 0x7f54f27ebac0 in ?? ()
>> #7 0x in ?? ()
>>
>> so it's crashing with mpm_event and without mpm_event. And it does with
>> core mod_http2 and mod_http2 v1.8.8.
>>
>> Is a regression in mod_http2 possible?
m upstream sources. May this be relevant?
Still not oberving any crashes running apache 2.4.23.
Greets,
Stefan
Am 19.01.2017 um 08:22 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> Apache 2.4.25 + mpm_event V7 and core mod_http2:
> Core was generated by `/usr/local/apac
Hi,
Am 19.01.2017 um 09:11 schrieb Yann Ylavic:
> On Thu, Jan 19, 2017 at 9:05 AM, Stefan Priebe - Profihost AG
> wrote:
>> With a vanilla apache 2.4.25 i got this one:
>>
>> Core was generated by `/usr/local/apache2/bin/httpd -k start'.
>> Program terminate
?? ()
#3 0x7f7d7112ca8c in ?? ()
#4 0x7f7d7112ca90 in ?? ()
#5 0x7f7d60a4bad0 in ?? ()
#6 0x in ?? ()
Am 19.01.2017 um 09:20 schrieb Stefan Priebe - Profihost AG:
> Hi,
> Am 19.01.2017 um 09:11 schrieb Yann Ylavic:
>> On Thu, Jan 19, 2017 at 9:05 AM, S
x7fb6599100a0 in ?? ()
#5 0x7fb659910f70 in ?? ()
#6 0x7fb65bfeeac0 in ?? ()
#7 0x in ?? ()
not all the others like with v1.8.8. So may this be a different one?
Stefan
Am 19.01.2017 um 09:21 schrieb Stefan Priebe - Profihost AG:
> And another one:
>
&
n ?? ()
#6 0x in ?? ()
Greets,
Stefan
>
> Cheers,
>
> Stefan
>
>> Am 19.01.2017 um 11:39 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi,
>>
>> with V7 and mod_http2 core i'm always seeing exactly THIS trace and
>> inst
gt; Cheers, Stefan
>
>
>
>
>
>> Am 19.01.2017 um 12:45 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Am 19.01.2017 um 11:56 schrieb Stefan Eissing:
>>> Stefan,
>>>
>>> yes, that is a known one that was addressed in v1.8.7. But
n ?? ()
#17 0x0004 in ?? ()
#18 0x7f4c206f50a0 in ?? ()
#19 0x7f4c22fec3c0 in ?? ()
#20 0x in ?? ()
i've now removed any mpm_event patch and try to look again at v1.8.8 +
your patch.
Stefan
>
>> Am 19.01.2017 um 15:00 schrieb Stefan Priebe - Profihost AG
>&
:35 schrieb Yann Ylavic:
> Hi,
>
> On Thu, Jan 19, 2017 at 3:00 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> @Yann:
>> should i use V7 or V6?
>
> I'd prefer you'd use none (such that we can verify the patch with
> stock 2.4.25, modulo mod_http2
I'm now testing stock 2.4.25 + patch.
May this configure option have an influence?
--enable-nonportable-atomics=yes
Greets,
Stefan
Am 19.01.2017 um 15:35 schrieb Yann Ylavic:
> Hi,
>
> On Thu, Jan 19, 2017 at 3:00 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> @Y
ecac0 in ?? ()
#7 0x in ?? ()
Stefan
Am 19.01.2017 um 16:28 schrieb Stefan Priebe - Profihost AG:
> I'm now testing stock 2.4.25 + patch.
>
> May this configure option have an influence?
> --enable-nonportable-atomics=yes
>
> Greets,
> Stefan
>
>
i need to pass a specific option to configure
Stefan
>> Am 19.01.2017 um 16:30 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> With stock 2.4.25 + patch i'm getting this one again:
>> (gdb) bt
>> #0 0x00521dcd in h2_stream_out_prepare ()
>&g
0x7fc1c1cc262d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 19.01.2017 um 16:45 schrieb Stefan Priebe - Profihost AG:
>
> Am 19.01.2017 um 16:34 schrieb Stefan Eissing:
>> Yann might already have asked this: any chance to compile with symbols and
>> get a more readable stacktr
>> #0 0x7f204f922d63 in apr_pool_cleanup_kill () from
>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0
>> #1 0x7f204f922e21 in apr_pool_cleanup_run () from
>> /usr/lib/x86_64-linux-gnu/libapr-1.so.0
>> #2 0x0055ffe9 in process_lingering_close ()
>
o.6
Stefan
Am 19.01.2017 um 21:48 schrieb Stefan Eissing:
> On top please. There is only one way: forward!
>
>> Am 19.01.2017 um 21:47 schrieb Stefan Priebe - Profihost AG
>> :
>>
>>
>> Am 19.01.2017 um 21:39 schrieb Stefan Eissing:
>>> Thanks, Stefan. Can yo
x27;t ;-) i've just a bunch of live webshops producing this. So
just real users - most probably GET + POST.
Stefan
>
> Thanks for the help!
>
> Cheers,
>
> Stefan
>
>> Am 19.01.2017 um 22:01 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> new
Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
> Hi,
>
> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hi Stefan,
>>
>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
>>> this seems to be a tough bone to chew. Therefore we need
might this be a debian bug? i can't reproduce with apr-included.
Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
> Hi,
>
> On Fri, Jan 20, 2017 at 8:03 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hi Stefan,
>>
>> Am 19.01.2017 um 22:44 schrieb Stefan Eissing:
&
0.01.2017 um 12:49 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> might this be a debian bug? i can't reproduce with apr-included.
>>
>>> Am 20.01.2017 um 08:20 schrieb Yann Ylavic:
>>> Hi,
>>>
>>> On Fri, Jan 20, 2017 at 8:03 AM,
fan
>
>> Am 20.01.2017 um 13:18 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Will start retesting V6 patch. Should I use mod_http2 1.8.8 with or without
>> patches?
>>
>> Greets,
>> Stefan
>>
>> Excuse my typo sen
Sorry misstyped it's V7 with mod_http 1.8.8 unpatched.
Stefan
Excuse my typo sent from my mobile phone.
> Am 20.01.2017 um 16:23 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi,
>
> it crashed again with V6 and plain mod_http2 v1.8.8.
>
> This is the crash
Yes. Until now I got 4 traces. But all are the same pointing to apr kill pool.
Not like before where i got many different ones.
Greets,
Stefan
Excuse my typo sent from my mobile phone.
> Am 20.01.2017 um 17:44 schrieb Yann Ylavic :
>
> On Fri, Jan 20, 2017 at 5:41 PM, Stef
Am 20.01.2017 um 18:17 schrieb Yann Ylavic:
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
> wrote:
>> Yes. Until now I got 4 traces. But all are the same pointing to apr kill
>> pool. Not like before where i got many different ones.
>
> Could y
() from
/lib/x86_64-linux-gnu/libpthread.so.0
#16 0x7f129f14162d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 20.01.2017 um 18:17 schrieb Yann Ylavic:
> On Fri, Jan 20, 2017 at 5:51 PM, Stefan Priebe - Profihost AG
> wrote:
>> Yes. Until now I got 4 traces. But all
Looks like others have the same crashes too:
https://bz.apache.org/bugzilla/show_bug.cgi?id=60071
and
https://github.com/apache/httpd/commit/8e63c3c9372cd398f57357099aa941cbba695758
So it looks like mod_http2 is running fine now. Thanks a lot Stefan.
Yann i think i can start testing your mpm patc
*arg* it's just mod_proxy - just saw thread safety and apr bucket aloc.
Stefan
Am 22.01.2017 um 17:06 schrieb Stefan Priebe - Profihost AG:
> Looks like others have the same crashes too:
> https://bz.apache.org/bugzilla/show_bug.cgi?id=60071
> and
> https://github.com/ap
Am 22.01.2017 um 17:14 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> *arg* it's just mod_proxy - just saw thread safety and apr bucket aloc.
>
> ??? Can you elaborate? Is your finding the known hcheck bug or something else?
>
>> Stefan
>>
>
Am 22.01.2017 um 18:02 schrieb Eric Covener:
> On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hi Stefan,
>>
>> no i was mistaken customer isn't using mod_proxy - but I think this is
>> the patch causing me problems:
>&g
Am 22.01.2017 um 22:22 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Sun, Jan 22, 2017 at 8:00 PM, Stefan Priebe - Profihost AG
> wrote:
>> Am 22.01.2017 um 18:02 schrieb Eric Covener:
>>> On Sun, Jan 22, 2017 at 11:21 AM, Stefan Priebe - Profihost AG
>>> wrote
Am 23.01.2017 um 21:54 schrieb Stefan Eissing:
>
>> Am 22.01.2017 um 22:22 schrieb Yann Ylavic :
>>
>> @icing: Any special expectation in mod_h2 with regard to mpm workers
>> threads' lifetime (or keepalive connections that should stay alive for
>> the configured limit)?
>> I see that beam bucket
Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
>> Hi Stefan,
>>
>> On Mon, Jan 23, 2017 at 9:54 PM, Stefan Eissing
>> wrote:
>>>
>>> I am not aware of any special expectations now. Almost all is triggered by
>>> (parent) pool cleanups and is t
Am 24.01.2017 um 14:22 schrieb Yann Ylavic:
> On Tue, Jan 24, 2017 at 10:02 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> Am 23.01.2017 um 23:42 schrieb Yann Ylavic:
>>> On Mon, Jan 23, 2017 at 11:37 PM, Yann Ylavic wrote:
>>>> Hi Stefan,
>>&g
Am 24.03.2018 um 15:28 schrieb Eric Covener:
> On Sat, Mar 24, 2018 at 10:18 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> is there any reason why the srever-status output isn't:
>> - available through a local unix socket - so you can grab it even
might this be something - where mod_systemd can be extended? I have
never used it but it already seems to provide some stats.
Am 26.03.2018 um 12:17 schrieb Stefan Priebe - Profihost AG:
>
> Am 24.03.2018 um 15:28 schrieb Eric Covener:
>> On Sat, Mar 24, 2018 at 10:18 AM, S
Hello,
i've backported mod_systemd to httpd 2.4 which was / is very straight
forward.
Now i would like to build mod_systemd statically but don't get it.
While --enable-unixd=static work fine --enable-systemd=static still
builds it as a shared module.
Any hints?
Greets,
Stefan
Am 27.03.2018 um 13:52 schrieb Eric Covener:
> On Tue, Mar 27, 2018 at 7:45 AM, Stefan Priebe - Profihost AG
> wrote:
>> Hello,
>>
>> i've backported mod_systemd to httpd 2.4 which was / is very straight
>> forward.
>>
>> Now i would like t
Hi Stefan,
would it be possible to add some http2 stats into mod_systemd status?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
Am 04.04.2018 um 11:59 schrieb Stefan Eissing:
>
>> Am 30.03.2018 um 19:20 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Stefan,
>>
>> would it be possible to add some http2 stats into mod_systemd status?
>
> Sorry for the late reply. J
Hi Stefan,
as i've tried todo nearly the same some weeks ago i can tell you what i did.
Comment inline.
Am 24.05.2018 um 13:34 schrieb Stefan Eissing:
> So, we are lacking an option here to abort SSL connections without a vhost
> match, it seems. Something like
>
> SSLStrictSNIVHostCheck requi
Hi,
in twitter and other social media channels they're talking about a
current apache 0 day:
https://twitter.com/i/web/status/1087593706444730369
which wasn't handled / isn't currently fixed.
Some details are here:
https://github.com/hannob/apache-uaf
If this is true there will be exploits soon
Hi,
i'm trying to run the webgui of rabbitmq behind apache proxy while using
mod_rewrite.
RabbitMQ generates URLs like:
http://rabbit.example.com/#/queues/%2F/myqueue
but those always generate a 404
What i tried is:
AllowEncodedSlashes NoDecode or Yes
RewriteRule ^/?rabbitmq/(.*)$ http://172.1
33 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> i'm trying to run the webgui of rabbitmq behind apache proxy while using
> mod_rewrite.
>
> RabbitMQ generates URLs like:
> http://rabbit.example.com/#/queues/%2F/myqueue
>
> but those always generate a 404
&
Hi Yann,
Am 25.01.2017 um 01:41 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
> wrote:
>> Yann, thanks for the patch. I agree that the cleanups need to be killed in
>> the right place. Not certain if it was wrong before, but that part is not
>> easy to s
Am 25.01.2017 um 10:46 schrieb Stefan Eissing:
> Thanks Yann!
>
> Stefan: here is the patch as committed to trunk:
Up and running. Will report back.
>
>
> Cheers, Stefan
>
>> Am 25.01.2017 um 01:41 schrieb Yann Ylavic :
>>
>> Hi Stefan,
>>
>> On Tue, Jan 24, 2017 at 1:37 PM, Stefan Eissing
>>
Hello,
while digging through some apache logfiles i saw some strange entries:
"GET URL HTTP/2.0" 500 0
They all had a 500 status error code and a size of 0.
I'm able to reproduce them while clicking fast on a php site. For each
log line with status code 500 i get a STATUS (canceled) in my chrome
Am 25.01.2017 um 14:57 schrieb Yann Ylavic:
> Hi,
>
> On Wed, Jan 25, 2017 at 2:46 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> Is this a bug or a feature? Is it correct that it logs a 500 code?
>
> ErrorLog's file should tell more about the error.
No er
it's just wrong that mod_http2
generates a 500 in the logs.
Stefan
Am 25.01.2017 um 15:27 schrieb Stefan Priebe - Profihost AG:
> Am 25.01.2017 um 14:57 schrieb Yann Ylavic:
>> Hi,
>>
>> On Wed, Jan 25, 2017 at 2:46 PM, Stefan Priebe - Profihost AG
>> wrote:
>>
Am 25.01.2017 um 15:50 schrieb Stefan Eissing:
>
>> Am 25.01.2017 um 15:31 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Chrome docs says:
>>
>> "cancelled / net::ERR_ABORTED is intended to only be generated when a
>> user action causes a
Hi,
Am 25.01.2017 um 15:59 schrieb Eric Covener:
> On Wed, Jan 25, 2017 at 9:55 AM, Stefan Priebe - Profihost AG
> wrote:
>> I also saw some more entries with 0 byte size in logs if there is no
>> body. http/1.1 logs the header size as well.
>
> What's your log
Hi Stefan,
did you already had the time to look at the 500 status code in case of
canceled requests?
Stefan
Am 25.01.2017 um 15:55 schrieb Stefan Priebe - Profihost AG:
>
> Am 25.01.2017 um 15:50 schrieb Stefan Eissing:
>>
>>> Am 25.01.2017 um 15:31 schrieb Stefan
:10 schrieb Stefan Priebe - Profihost AG:
> Am 25.01.2017 um 10:46 schrieb Stefan Eissing:
>> Thanks Yann!
>>
>> Stefan: here is the patch as committed to trunk:
>
> Up and running. Will report back.
>
>>
>>
>> Cheers, Stefan
>>
>>>
s.
thanks will report back most probably on monday.
Stefan
> Cheers, Stefan
>
>> Am 26.01.2017 um 16:36 schrieb Stefan Eissing :
>>
>> Hi, will do that tomorrow.
>>
>>> Am 26.01.2017 um 16:35 schrieb Stefan Priebe - Profihost AG
>>> :
>>>
Hi Yann,
Hi Stefan,
any ideas?
Stefan
Am 27.01.2017 um 20:30 schrieb Ruediger Pluem:
>
>
> On 01/27/2017 08:10 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Yann,
>>
>> this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch:
>> Progr
Am 02.02.2017 um 11:09 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Tue, Jan 31, 2017 at 4:01 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> any ideas?
>
> I wonder if the attached patch (related to mod_ssl and proposed for
> another segfault report) could help
nn Ylavic:
> Hi Stefan,
>
> On Tue, Jan 31, 2017 at 4:01 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> any ideas?
>
> I wonder if the attached patch (related to mod_ssl and proposed for
> another segfault report) could help in your case.
>
> Would you mind give it a try?
>
>
> Thanks,
> Yann.
>
Hallo,
up and running (apache 2.4.25 + mpm_event V7 + mpd_http2 v1.8.11 +
mod_ssl patch + your new allocator patch). Will report back.
Greets,
Stefan
Am 06.02.2017 um 01:19 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Sun, Feb 5, 2017 at 7:51 PM, Stefan Priebe - Profihost AG
> wrote:
,
dummy=0x547d8caf3534b) at event.c:1837
#5 0x7f2bc8ff20a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#6 0x7f2bc8d2762d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 06.02.2017 um 09:33 schrieb Stefan Priebe - Profihost AG:
> Hallo,
>
> up an
Am 06.02.2017 um 11:56 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Mon, Feb 6, 2017 at 9:57 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> your last patch results in multiple crashes every second:
>
> Sorry about that, the changes in mpm_event were incorrect (the mut
Hi,
so i should test the mpm event part from Yann + your http2 part?
Stefan
Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
> Yes, that was mixing the order. The attached v4 compiles and runs the h2
> tests for me without errors.
>
>
>
>
>
>> Am 06.02.2017 um 14:43 schrieb Yann Ylavic :
>>
tefan
> -Stefan
>
>> Am 06.02.2017 um 15:41 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi,
>>
>> so i should test the mpm event part from Yann + your http2 part?
>>
>> Stefan
>>
>> Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
>&
Am 06.02.2017 um 16:06 schrieb Stefan Eissing:
> It does, at the end. Traversed the directories in different order it seems.
*arg* sorry
>
>> Am 06.02.2017 um 16:05 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Am 06.02.2017 um 16:03 schrieb Stefan Eissing:
Hi Stefan,
this one does not apply on top of yann's
mpm_event_listener_wakeup_bug57399_V7.patch patch.
Stefan
Am 06.02.2017 um 15:34 schrieb Stefan Eissing:
> Yes, that was mixing the order. The attached v4 compiles and runs the h2
> tests for me without errors.
>
>
>
>
>
>> Am 06.02.2017 u
Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> this one does not apply on top of yann's
> mpm_event_listener_wakeup_bug57399_V7.patch patch.
i've now used his patch to mpm and yours for mod_http2.
Stefan
>
> Stefan
> Am 06.02.2017
/lib/x86_64-linux-gnu/libc.so.6
Am 06.02.2017 um 22:24 schrieb Stefan Priebe - Profihost AG:
> Am 06.02.2017 um 22:22 schrieb Stefan Priebe - Profihost AG:
>> Hi Stefan,
>>
>> this one does not apply on top of yann's
>> mpm_event_listener_wakeup_bug57399_V7.patch p
;
> Hope to give you something better to verify in your environment soon.
Just tell me i'm ready to test.
Greets,
Stefan
> Cheers,
>
> Stefan
>
>> Am 07.02.2017 um 20:56 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi,
>>
>> got t
Hi,
up and running - Thanks!
Greets,
Stefan
Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
> Stefan,
>
> if you'd like, please throw
> https://github.com/icing/mod_h2/releases/tag/v1.9.0
> into your pit of segfaults and let's see if we find a new one!
>
> Many thanks for testing.
>
> Stefan E
1 - 100 of 164 matches
Mail list logo