Re: mod_http2 and Frequent wake-ups for mpm_event

[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:
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  allocator_free (node=0x0, allocator=0x7f8974080c90)
> at memory/unix/apr_pools.c:381
> #0  allocator_free (node=0x0, allocator=0x7f8974080c90)
> at memory/unix/apr_pools.c:381
> #1  apr_pool_clear (pool=0x7f89740830d8) at memory/unix/apr_pools.c:793

pool from above != pool_to_recycle from below is strange.

> #2  0x5611421447a8 in ap_push_pool (queue_info=0x0,

queue_info NULL? That looks bad.

> pool_to_recycle=0x7f8974080c98) at fdqueue.c:234
> #3  0x56114213faea in process_lingering_close (cs=0x7f8974083368,
> pfd=0x561142cc97f8) at event.c:1513
> #4  0x561142143620 in listener_thread (thd=0x0, dummy=0x54716c3684bbc)
> at event.c:1837
> #5  0x7f8989bb20a4 in start_thread ()
>from /lib/x86_64-linux-gnu/libpthread.so.0
> #6  0x7f89898e762d in clone () from /lib/x86_64-linux-gnu/libc.so.6

Regards

Rüdiger

Re: mod_http2 and canceled requests logs status 500 internal server error code

[Stefan Priebe - Profihost AG]

Hi,

Am 27.01.2017 um 18:59 schrieb Stefan Eissing:
> Out now: https://github.com/icing/mod_h2/releases/tag/1.8.11 fresh from 
> Apache svn trunk+2.4.x
> 
> I could not reproduce the 500 behaviour, but added a check on the recent 
> change on response generation. Hope this helps.

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 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 Priebe - Profihost AG 
>> :
>>
>> Chrome docs says:
>>
>> "cancelled / net::ERR_ABORTED is intended to only be generated when a
>> user action causes a load to be interrupted. This can happen when a new
>> navigation interrupts an existing one, or when the user clicks the STOP
>> button"
>>
>> This matches my click assumption. I think it's just wrong that mod_http2
>> generates a 500 in the logs.
>
> I agree. Might be a new one related to the 304 fix in 1.8.10.

 Would be great if you can have a look. It confuses the users while
 reading their logs.

 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.

 Greets,
 Stefan

>>
>> 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:
>
> 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 error log does not have an entry with the same or nearly the same
>>> timestamp.
>>>
>>> Stefan
>>>

 Regards,
 Yann.

>
> Stefan Eissing
>
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
>
>>
>> Stefan Eissing
>>
>> bytes GmbH
>> Hafenstrasse 16
>> 48155 Münster
>> www.greenbytes.de
>>
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Re: mod_http2 and Frequent wake-ups for mpm_event

[Stefan Priebe - Profihost AG]

Hi Yann,

this is now a segfault with mod_http2 + beam v4 patch + mpm v7 patch:
Program terminated with signal SIGSEGV, Segmentation fault.
#0  allocator_free (node=0x0, allocator=0x7f8974080c90)
at memory/unix/apr_pools.c:381
#0  allocator_free (node=0x0, allocator=0x7f8974080c90)
at memory/unix/apr_pools.c:381
#1  apr_pool_clear (pool=0x7f89740830d8) at memory/unix/apr_pools.c:793
#2  0x5611421447a8 in ap_push_pool (queue_info=0x0,
pool_to_recycle=0x7f8974080c98) at fdqueue.c:234
#3  0x56114213faea in process_lingering_close (cs=0x7f8974083368,
pfd=0x561142cc97f8) at event.c:1513
#4  0x561142143620 in listener_thread (thd=0x0, dummy=0x54716c3684bbc)
at event.c:1837
#5  0x7f8989bb20a4 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#6  0x7f89898e762d in clone () from /lib/x86_64-linux-gnu/libc.so.6


Stefan
Am 25.01.2017 um 12: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
>>
>>> 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 see for every combination.

 I did some rework and hope this makes it more readable. If you find the 
 time to look at it, feedback welcome.
>>>
>>> I still fear that if beam->pool gets destroyed while both
>>> beam_send_cleanup() and beam_cleanup() are registered, the former is
>>> called twice.
>>>
>>> I'd change:
>>>if (safe_send) {
>>>if (beam->send_pool && beam->send_pool != beam->pool) {
>>>apr_pool_cleanup_kill(beam->send_pool, beam, beam_send_cleanup);
>>>}
>>>status = beam_send_cleanup(beam);
>>>}
>>>
>>> with:
>>>if (safe_send) {
>>>if (beam->send_pool) {
>>>if (beam->send_pool != beam->pool) {
>>>apr_pool_cleanup_kill(beam->send_pool, beam, 
>>> beam_send_cleanup);
>>>}
>>>status = beam_send_cleanup(beam);
>>>}
>>>}
>>>
>>> since in the above case beam_send_cleanup is run first and sets 
>>> send_pool=NULL.
>>>
>>> Attached v3 with this only change w.r.t. v2.
>>> Otherwise, looks good to me, thanks!
>>> 
>>
>> Stefan Eissing
>>
>> bytes GmbH
>> Hafenstrasse 16
>> 48155 Münster
>> www.greenbytes.de
>>

Re: Summary: Broken FastCGI with httpd

[Jacob Champion]

On 01/27/2017 04:56 AM, Jim Jagielski wrote:

Let me relook over fpm-main... from what I saw, there are only 2
logic paths: one if Apache and the other for everybody-else...
and the Apache path only kicks in if it sees the proxy:balancer
or proxy:fcgi prefix.


Unfortunately there are at least three: non-Apache, "old" Apache, and 
"new" Apache (mod_proxy_fcgi). And the logic of those three paths 
overlaps -- they're not completely separate.


That's what makes this hard. If we remove the proxy: prefix now, PHP-FPM 
"old mode" fixups will kick in (in certain situations involving 
REDIRECT_URL etc.) even if there is nothing to fix up. That's what 
prompted this conversation.


--Jacob

Re: mod_http2 and canceled requests logs status 500 internal server error code

[Stefan Eissing]

Out now: https://github.com/icing/mod_h2/releases/tag/1.8.11 fresh from Apache 
svn trunk+2.4.x

I could not reproduce the 500 behaviour, but added a check on the recent change 
on response generation. Hope this helps.

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 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 Priebe - Profihost AG 
> :
> 
> Chrome docs says:
> 
> "cancelled / net::ERR_ABORTED is intended to only be generated when a
> user action causes a load to be interrupted. This can happen when a new
> navigation interrupts an existing one, or when the user clicks the STOP
> button"
> 
> This matches my click assumption. I think it's just wrong that mod_http2
> generates a 500 in the logs.
 
 I agree. Might be a new one related to the 304 fix in 1.8.10.
>>> 
>>> Would be great if you can have a look. It confuses the users while
>>> reading their logs.
>>> 
>>> 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.
>>> 
>>> Greets,
>>> Stefan
>>> 
> 
> 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:
 
 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 error log does not have an entry with the same or nearly the same
>> timestamp.
>> 
>> Stefan
>> 
>>> 
>>> Regards,
>>> Yann.
>>> 
 
 Stefan Eissing
 
 bytes GmbH
 Hafenstrasse 16
 48155 Münster
 www.greenbytes.de
 
> 
> Stefan Eissing
> 
> bytes GmbH
> Hafenstrasse 16
> 48155 Münster
> www.greenbytes.de
> 

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Tue, Jan 24, 2017 at 5:22 AM, Reindl Harald  wrote:
>
> no, you are just a hypocrite trying to forbid others voice their opinion in
> their weay but not follow your own rules to always say critics nice and
> lovely and so you have no point to play internet police on mailing lists any
> longer

In the spirit of fairness, one for you too to keep the score even:
Keep stuff like this off of our lists.  It's not what we're all
subscribed for.

-- 
Eric Covener
cove...@gmail.com

Re: [proposed] 2.4 Maintenance SIG

[Jim Jagielski]

https://www.youtube.com/watch?v=jKGjOE_7bYI

Re: [proposed] 2.4 Maintenance SIG

[Ruediger Pluem]

On 01/27/2017 04:21 PM, Eric Covener wrote:
> On Fri, Jan 27, 2017 at 10:07 AM, Nick Edwards  
> wrote:
>> You need some edumacation
> 
> We're well aware of his notoriety and their relationship.   I
> personally don't care about motives or backstory for off-topic
> shit-posting.
> 

+1

Regards

Rüdiger

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Fri, Jan 27, 2017 at 10:07 AM, Nick Edwards  wrote:
> You need some edumacation

We're well aware of his notoriety and their relationship.   I
personally don't care about motives or backstory for off-topic
shit-posting.

Re: [proposed] 2.4 Maintenance SIG

[Nick Edwards]

You need some edumacation, I've avoided getting involved in these comments
but I think this has to be said.

Reindl is a long time well known troll, a highly caustic and abusive one,
he's been kicked off more industry mailing lists than you've probably had
hot dinners for it, some other lists, he's just moderated on, but replies
constantly to posters in private, he also abuses them in private, this led
to him being blacklisted in a DNSBL that Noel happens to be one of the
maintainers of, so Reindl constantly tries to bait him, I heard they
mutually had agreement never to talk to each other, but Reindl does not
know how to keep promises, especially when others come out against Noel
like has gone on here, Reindl will always be in it (you vna see this from
his usual lame comment), I'm not  a real fan of Noel, I know him
personally, I worked for him in a national ISP - before he sacked me :)
He's a decent guy who will go out his way to help others, truth be told I
probably had a bout 10 warnings where most get 3 so he has a lot patience,
but if he has an opinion he will always express it and wont walk on cotton
wool in doing so, some respect him for it, others detest him for it, he's
always told me he doesnt care, because at least people know where they
stand with him.


as for Reindl, well, he cant see what hes doing wrong, despite being kicked
off all those lists, he's just a lost cause.
this ends your edumacation.


On Sat, Jan 28, 2017 at 12:11 AM, Eric Covener  wrote:

>
> On Fri, Jan 27, 2017 at 6:22 AM, Noel Butler 
> wrote:
>
>> I never object to any sensible opinion.
>>
>> Harry, you were warned never to reply or respond to me, because you know
>> what happens if you do, i'll assume you were off your meds again when you
>> clicked reply and forgot.
>>
> You both need to keep it topical and stop the mutual harassment.  Enough
> is enough.
>

Openssl 1.1.x compatibility

[Luca Toscano]

Hi everybody,

once in a while on users@ it is asked if httpd 2.4.x supports Openssl
1.1.x, but afaik
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x-openssl-1.1.0-compat
is still work in progress. Any plans to release this work during the next
months? It would be really great, but I am completely ignorant about how
feasible it would be and if we hit road blockers that stopped the
development.

Thanks!

Luca

Re: [proposed] 2.4 Maintenance SIG

[Eric Covener]

On Fri, Jan 27, 2017 at 6:22 AM, Noel Butler  wrote:

> I never object to any sensible opinion.
>
> Harry, you were warned never to reply or respond to me, because you know
> what happens if you do, i'll assume you were off your meds again when you
> clicked reply and forgot.
>
You both need to keep it topical and stop the mutual harassment.  Enough is
enough.

Re: Summary: Broken FastCGI with httpd

[Jim Jagielski]

Ahh... thanks! Yeah, it looks like other than removing the
prefix (and host:port), it does nothing more Apache-wise.
> On Jan 27, 2017, at 8:28 AM, Luca Toscano  wrote:
> 
> 
> 
> 2017-01-27 13:56 GMT+01:00 Jim Jagielski :
> 
> > On Jan 26, 2017, at 6:13 PM, Jacob Champion  wrote:
> >
> >
> > +1 (just not for 2.4.26, per my OP in the thread -- there is no way I can 
> > find around the current PHP-FPM "fixups" without compatibility-breaking 
> > behavior).
> >
> 
> Let me relook over fpm-main... from what I saw, there are only 2
> logic paths: one if Apache and the other for everybody-else...
> and the Apache path only kicks in if it sees the proxy:balancer
> or proxy:fcgi prefix.
> 
> My thought was to have mod_proxy_fcgi now start sending "correct"
> values for these envvars requiring NO fixups... ie, PHP-FPM
> will handle those envvars as it does for everybody else.
> 
> Isn't that the better solution? Or is your concern about non PHP-FPM
> fcgi backends and *that* compatibility concern?
> 
> 
> HHVM is another important PHP FCGI backend that might be interesting to take 
> into consideration. It seems that there is a check for mod_proxy_fcgi's 
> prefix in here too:
> 
> https://github.com/facebook/hhvm/blob/HHVM-3.17/hphp/runtime/server/fastcgi/fastcgi-transport.cpp#L243-L244
> 
> Luca

Re: Summary: Broken FastCGI with httpd

[Luca Toscano]

2017-01-27 13:56 GMT+01:00 Jim Jagielski :

>
> > On Jan 26, 2017, at 6:13 PM, Jacob Champion 
> wrote:
> >
> >
> > +1 (just not for 2.4.26, per my OP in the thread -- there is no way I
> can find around the current PHP-FPM "fixups" without compatibility-breaking
> behavior).
> >
>
> Let me relook over fpm-main... from what I saw, there are only 2
> logic paths: one if Apache and the other for everybody-else...
> and the Apache path only kicks in if it sees the proxy:balancer
> or proxy:fcgi prefix.
>
> My thought was to have mod_proxy_fcgi now start sending "correct"
> values for these envvars requiring NO fixups... ie, PHP-FPM
> will handle those envvars as it does for everybody else.
>
> Isn't that the better solution? Or is your concern about non PHP-FPM
> fcgi backends and *that* compatibility concern?
>
>
HHVM is another important PHP FCGI backend that might be interesting to
take into consideration. It seems that there is a check for
mod_proxy_fcgi's prefix in here too:

https://github.com/facebook/hhvm/blob/HHVM-3.17/hphp/runtime/server/fastcgi/fastcgi-transport.cpp#L243-L244

Luca

Re: Summary: Broken FastCGI with httpd

[Jim Jagielski]

> On Jan 26, 2017, at 6:13 PM, Jacob Champion  wrote:
> 
> 
> +1 (just not for 2.4.26, per my OP in the thread -- there is no way I can 
> find around the current PHP-FPM "fixups" without compatibility-breaking 
> behavior).
> 

Let me relook over fpm-main... from what I saw, there are only 2
logic paths: one if Apache and the other for everybody-else...
and the Apache path only kicks in if it sees the proxy:balancer
or proxy:fcgi prefix.

My thought was to have mod_proxy_fcgi now start sending "correct"
values for these envvars requiring NO fixups... ie, PHP-FPM
will handle those envvars as it does for everybody else.

Isn't that the better solution? Or is your concern about non PHP-FPM
fcgi backends and *that* compatibility concern?

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 24/01/2017 20:22, Reindl Harald wrote:

> Am 23.01.2017 um 02:52 schrieb Noel Butler: 
> 
>> Perhaps the only person who wont bend over and take it up the arse like
>> some people here expect, if I have an opinion, i'll voice it
> 
> no, you are just a hypocrite trying to forbid others voice their opinion in 
> their weay but not follow your own rules to always say critics nice and 
> lovely and so you have no point to play internet police on mailing lists any 
> longer

I never object to any sensible opinion. 

Harry, you were warned never to reply or respond to me, because you know
what happens if you do, i'll assume you were off your meds again when
you clicked reply and forgot. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 23/01/2017 19:14, Stefan Eissing wrote:

> Am 23.01.2017 um 02:52 schrieb Noel Butler :
> 
> On 20/01/2017 07:45, Jacob Champion wrote:
> 
> On 01/19/2017 12:52 PM, Noel Butler wrote: Frequent releases set off alarms 
> in system admins minds, frequent
> releases give the view of unstable/unreliable software, and that is the
> largest cause of movement to an alternative. 
> So, the last [1] two [2] times you've pushed this viewpoint, you've been the 
> only one. You remain the only person I've ever known to hold this opinion, 
> and I speak as someone who maintained a long-term-

Perhaps the only person who wont bend over and take it up the arse like
some people here expect, if I have an opinion, i'll voice it, I have the
advantage of looking at this from also a system admins perspective, not
just a coders, and yes, they very well all too often differ. 
Your opinion and courageous behaviour is noted. Since I have the same
advantage as you and come to different conclusions, maybe there's a
hidden variable here somewhere.

Stefan Eissing

bytes GmbH
Hafenstrasse 16
48155 Münster
www.greenbytes.de [1]

And if we ask ten others in same vote as us, we'll probably end up with
ten more difference of opinions 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [2] and ODF [3] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.greenbytes.de
[2] http://www.adobe.com/
[3] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature

Re: [proposed] 2.4 Maintenance SIG

[Noel Butler]

On 24/01/2017 13:58, William A Rowe Jr wrote:

> On Sun, Jan 22, 2017 at 7:52 PM, Noel Butler  wrote:
> 
>> Perhaps the only person who wont bend over and take it up the arse like some 
>> people here expect, if I have an opinion, i'll voice it
> 
> Noel, your immediately prior post was an interesting example, although I fail 
>  
> to see how that particular example applies. When a project is dysfunctional  
> in multiple aspects, it is easy to pin the tail on the donkey of your 
> personally 
> most aggravating aspect. 
> 
> This specif post was not welcome, helpful, nor productive. 
> 
> You may want to press pause on sharing your voice for the time being, until  
> you find a way to express it in a more useful manner? Shouting doesn't help, 
> nor do expletives. If you need to be reminded again, our chair will take care 
>  
> of executing the unsubscribe function.

Riiight, So I shall only speak if I want to be a conformist and
agree?  If I have an opinion that differs you want me to shut up? 

riight. 

-- 
Kind Regard, 

Noel Butler 

This Email, including any attachments, may contain legally 
privileged
information, therefore remains confidential and subject to copyright
protected under international law. You may not disseminate, discuss, or
reveal, any part, to anyone, without the authors express written
authority to do so. If you are not the intended recipient, please notify
the sender then delete all copies of this message including attachments,
immediately. Confidentiality, copyright, and legal privilege are not
waived or lost by reason of the mistaken delivery of this message. Only
PDF [1] and ODF [2] documents accepted, please do not send proprietary
formatted documents 

 

Links:
--
[1] http://www.adobe.com/
[2] http://en.wikipedia.org/wiki/OpenDocument

signature.asc
Description: OpenPGP digital signature