Hi,
not sure whether this is related to mod_http2 v1.10.0 or is something else.
I've seen two servers where old httpd processes get stuck.
server-status looks like this:
SlotPID StoppingConnections Threads Async connections
total accepting busyidlewriting keep
THX
Stefan
Am 05.04.2017 um 12:11 schrieb Wolfgang Bumiller:
> applied to both master and stable-4
>
> On Tue, Apr 04, 2017 at 04:43:31PM +0200, Thomas Lamprecht wrote:
>> From: Stefan Priebe
>>
>> This allows us to use management software for files inside of /etc/p
Hi,
i have sometimes problems with the pve api - just closing the connection
or giving me a timeout and i wanted to debug this.
I wanted to raise the workers - but wasn't able to find an option to
change the workers of pveproxy and or pvedaemon.
Greets,
Stefan
___
Never mind.I found the culprit the file is just read to early by other nodes.
Stefan
Excuse my typo sent from my mobile phone.
> Am 22.03.2017 um 15:19 schrieb Stefan Priebe - Profihost AG
> :
>
> Hi,
>
> this works fine with /var/log/pve/tasks which is the folder i
there anything special
with the migration log? All others get the correct state of OK.
Greets
Stefan
Am 11.03.2017 um 08:28 schrieb Dietmar Maurer:
>
>
>> On March 10, 2017 at 9:24 PM Stefan Priebe - Profihost AG
>> wrote:
>>
>>
>>
>> Am 10.03.2017 um 2
Hi Thomas,
thanks and yes if you will do a V5 it would be great!
Stefan
Am 21.03.2017 um 10:46 schrieb Thomas Lamprecht:
> Hi,
>
> On 03/20/2017 03:11 PM, Stefan Priebe wrote:
>> This allows us to use management software for files inside of /etc/pve.
>> f.e. saltstack whi
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Reviewed-by: Thomas Lamprecht
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 38 +-
1 file changed, 37 insertions
V4:
- allow chmod for priv path as well
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
Am 19.03.2017 um 21:42 schrieb Dietmar Maurer:
>> To me the main question is why does pve-cluster provide a default of 0
>> which disables iptables for bridges and makes pve-firewall useless for
>> linux bridges.
>
> AFAIR this is for performance reasons ...
sure but pve-firewall isn't working i
Hi,
Am 19.03.2017 um 14:44 schrieb Dietmar Maurer:
>> After digging around for some weeks i found out that the chain FORWARD
>> does not receive packets anymore?
>
> And hints in syslog?
No the reason is simply that
net.bridge.bridge-nf-call-iptables
is 0 again. Most probably because /etc/sysctl.
Hello list,
i'm going crazy with a problem i don't understand.
After some time the pve-firewall stops working to me. It doesn't filter
any packets anymore. If i restart pve-firewall everything is fine again.
After digging around for some weeks i found out that the chain FORWARD
does not receive
Hi,
Am 16.03.2017 um 18:05 schrieb Luca Toscano:
>
>
> 2017-03-16 15:24 GMT+01:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> Hi,
>
> Am 16.03.2017 um 12:26 schrieb Luca Toscano:
> > Hi Stefan,
> >
>
Hi,
Am 16.03.2017 um 12:26 schrieb Luca Toscano:
> Hi Stefan,
>
> 2017-03-16 12:14 GMT+01:00 Stefan Priebe - Profihost AG
> mailto:s.pri...@profihost.ag>>:
>
> Hi Yann,
>
> no sure whether this is due to your mpm event patch.
>
> From time to ti
Hi Yann,
no sure whether this is due to your mpm event patch.
>From time to time i see the following error mesages in my logs and the
only chance to fix it is to restart apache.
[Thu Mar 16 01:00:35.445184 2017] [mpm_event:error] [pid 27485:tid
140212799559552] AH: scoreboard is full, not at Max
thread.so.0
#24 0x7f85d490262d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 12.03.2017 um 19:53 schrieb Stefan Priebe - Profihost AG:
> Thanks. Installed.
>
> Greets,
> Stefan
> Am 12.03.2017 um 15:58 schrieb Stefan Eissing:
>> Stefan,
>>
>> I would b
Thanks Qu, removing BTRFS_I from the inode fixes this issue to me.
Greets,
Stefan
Am 14.03.2017 um 03:50 schrieb Qu Wenruo:
>
>
> At 03/13/2017 09:26 PM, Stefan Priebe - Profihost AG wrote:
>>
>> Am 13.03.2017 um 08:39 schrieb Qu Wenruo:
>>>
>>>
&g
Am 13.03.2017 um 08:39 schrieb Qu Wenruo:
>
>
> At 03/13/2017 03:26 PM, Stefan Priebe - Profihost AG wrote:
>> Hi Qu,
>>
>> Am 13.03.2017 um 02:16 schrieb Qu Wenruo:
>>>
>>> At 03/13/2017 04:49 AM, Stefan Priebe - Profihost AG wrote:
>>>&g
Hi Qu,
Am 13.03.2017 um 02:16 schrieb Qu Wenruo:
>
> At 03/13/2017 04:49 AM, Stefan Priebe - Profihost AG wrote:
>> Hi Qu,
>>
>> while V5 was running fine against the openSUSE-42.2 kernel (based on
>> v4.4).
>
> Thanks for the test.
>
>> V7 re
Hi Qu,
while V5 was running fine against the openSUSE-42.2 kernel (based on v4.4).
V7 results in OOPS to me:
BUG: unable to handle kernel NULL pointer dereference at 01f0
IP: [] __endio_write_update_ordered+0x33/0x140 [btrfs]
PGD 14e18d4067 PUD 14e1868067 PMD 0
Oops: [#1] SMP
Mod
Thanks. Installed.
Greets,
Stefan
Am 12.03.2017 um 15:58 schrieb Stefan Eissing:
> Stefan,
>
> I would be very interested in hearing how v1.9.3 fares in your environment:
> - I found and fixed a race in connection shutdown that could potentially
> explain your sometimes observed crashes
> - I ch
Great thanks. Is there any reason why we don't use the existing pmxcfs for that
path as well?
Stefan
Excuse my typo sent from my mobile phone.
> Am 11.03.2017 um 08:28 schrieb Dietmar Maurer :
>
>
>
>> On March 10, 2017 at 9:24 PM Stefan Priebe - Profihost AG
>&
Am 10.03.2017 um 21:20 schrieb Dietmar Maurer:
>> Sure. Great. So there's no problem if all files got shared between
>> nodes?
>
> Sorry, but I never tested that.
>
>> I've never looked at the code for the active and index files...
>
> I guess you would need some cluster wide locking, or use s
Am 10.03.2017 um 20:54 schrieb Dietmar Maurer:
>> Is there any reason to no run /var/log/pve on ocfs2? So that it is
>> shared over all nodes?
>
> never tried. But I guess it is no problem as long as ocfs2 works (cluster
> quorate).
Sure. Great. So there's no problem if all files got shared betw
Hello,
i don't like that i don't have a complete task history of a VM after
migration.
Is there any reason to no run /var/log/pve on ocfs2? So that it is
shared over all nodes?
Greets,
Stefan
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://
thanks for review. V4 sent.
Stefan
Am 10.03.2017 um 10:20 schrieb Thomas Lamprecht:
> small comment inline,
>
> On 03/09/2017 08:17 PM, Stefan Priebe wrote:
>> This allows us to use management software for files inside of /etc/pve.
>> f.e. saltstack which rely on being ab
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Reviewed-by: Thomas Lamprecht
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 34 +-
1 file changed, 33 insertions(+), 1
fixed the intend in fuse fuse_operations as well
___
pve-devel mailing list
pve-devel@pve.proxmox.com
http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/data
Hello Thomas,
Am 09.03.2017 um 18:09 schrieb Thomas Lamprecht:
> On 03/09/2017 05:26 PM, Stefan Priebe wrote:
>> This allows us to use management software for files inside of /etc/pve.
>> f.e. saltstack which rely on being able to set uid,gid and chmod
>>
>> S
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/data
to keep looking...
May be Yann has an idea? May be it's not related to http2 at all?
Stefan
>> Am 09.03.2017 um 17:32 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Stefan,
>>
>> while doing longer testing i can say that also the version which was
dy has / supports.
At least saltstack always sets chmod and chown values and fails it it
can't. Now it believes that it was successful while providing salt with
the correct values:
user: root
group: www-date
chmod 0640
Greets,
Stefan
>
>> On March 9, 2017 at 5:26 PM Stefan Priebe wrote:
Hi Stefan,
while doing longer testing i can say that also the version which was
working for 4 days segfaults. So it was never solved ;-( Sorry about
that. Testing was just too short.
Greets,
Stefan
Am 05.03.2017 um 14:49 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> yes this
This allows us to use management software for files inside of /etc/pve.
f.e. saltstack which rely on being able to set uid,gid and chmod
Signed-off-by: Stefan Priebe
---
data/src/pmxcfs.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git
version ??
>
> Is this correct?
>
>> Am 04.03.2017 um 22:34 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Stefan,
>>
>> current trace - not sure whether this is http2 related at all:
>>
>> Core was generated by `/usr/local/apache/bin/h
from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 03.03.2017 um 21:02 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> live. Sorry for the late reply.
>
> Stefan
>
> Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
>> Meh, my mistake. Sorry about that. Did not cleanu
Hi Stefan,
live. Sorry for the late reply.
Stefan
Am 28.02.2017 um 11:49 schrieb Stefan Eissing:
> Meh, my mistake. Sorry about that. Did not cleanup properly. Dare you with an
> improved version:
>
>
>
>
>
>> Am 28.02.2017 um 08:41 schrieb Stefan Priebe - Pr
Eissing:
> Damnit. Can you try the attached patch on top of mod_http2 v1.9.2? This one
> sets a mutex on the main connection allocator if missing and is pretty close
> to the version we ran successfully with on your site for days.
>
> Thanks again!
>
> -Stefan
>
lone () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) (gdb) quit
Stefan
Am 26.02.2017 um 19:46 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
>
> currently everything fine. No segfaults.
>
> Stefan
>
> Am 25.02.2017 um 20:40 schrieb Stefan Priebe - Profihost AG:
>> Hi
Hi,
can please anybody comment on that one? Josef? Chris? I still need those
patches to be able to let btrfs run for more than 24hours without ENOSPC
issues.
Greets,
Stefan
Am 27.02.2017 um 08:22 schrieb Qu Wenruo:
>
>
> At 02/25/2017 04:23 PM, Stefan Priebe - Profihost AG wrote:
&
Hi Stefan,
currently everything fine. No segfaults.
Stefan
Am 25.02.2017 um 20:40 schrieb Stefan Priebe - Profihost AG:
> Hi Stefan,
> Am 25.02.2017 um 13:51 schrieb Stefan Eissing:
>> Stefan,
>>
>> whenever you have time, please deploy
>> https://github.com/ic
tween placing that on the main conn (as we had
> in the crash free version) and 1.9.1 behaviour. Thanks!
done. But please keep in mind that this crash might be very rare and
might even have happened with v1.9.0 if we've waited more time.
Greets,
Stefan
> -Stefan
>
>> Am
Dear Qu,
any news on your branch? I still don't see it merged anywhere.
Greets,
Stefan
Am 04.01.2017 um 17:13 schrieb Stefan Priebe - Profihost AG:
> Hi Qu,
>
> Am 01.01.2017 um 10:32 schrieb Qu Wenruo:
>> Hi Stefan,
>>
>> I'm trying to push it to for-next
16, 258, 771, 1026, 1283}, __u6_addr32 = {3305048842, 1094912,
50528514, 84083714}}}
Stefan
Am 24.02.2017 um 14:18 schrieb Yann Ylavic:
> Hi Stefan (Priebe),
>
> Is IPv6 (really) involved in your network?
>
> Could you please show up the gdb output of the below ?
>
> On
No we don't use IPv6 at all. Do you still need those values?
Greets,
Stefan
Excuse my typo sent from my mobile phone.
> Am 24.02.2017 um 14:18 schrieb Yann Ylavic :
>
> Hi Stefan (Priebe),
>
> Is IPv6 (really) involved in your network?
>
> Could you please show up t
a4 in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#13 0x7f459649662d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 23.02.2017 um 07:59 schrieb Stefan Priebe - Profihost AG:
> Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> On Wed
Am 22.02.2017 um 12:22 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Wed, Feb 22, 2017 at 11:32 AM, Stefan Priebe - Profihost AG
> wrote:
>>
>> @Yann how should i test? Vanilla 2.4.25 + MPM V7 + mod_http2 v1.9.1?
>
> Yes, I think this is the right thing to do fo
Am 21.02.2017 um 09:40 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi Yann,
>>
>> Am 20.02.2017 um 16:38 schrieb Yann Ylavic:
>>> On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
>>> wrote:
>>>>
>>>> still no
Hi Yann,
Am 20.02.2017 um 16:38 schrieb Yann Ylavic:
> On Wed, Feb 15, 2017 at 8:53 PM, Stefan Priebe - Profihost AG
> wrote:
>>
>> still no segfaults.
>
> Great!
>
>>
>> @Yann
>> Are those patches (the addon on top of v7) and the one on top of mo
Hi,
still not a single segfault with mod_http2 1.9.0 - good work!
@Yann
Could you please tell me whether i should drop of your additional patches?
Greets,
Stefan
Am 09.02.2017 um 11:55 schrieb Stefan Priebe - Profihost AG:
Hi Stefan,
Am 09.02.2017 um 11:47 schrieb Stefan Eissing:
Stefan
Hi,
is there any chance to optimize btrfs_find_space_for_alloc / rb_next on
big devices?
I've plenty of free space but most of the time there's only low I/O but
high cpu usage. perf top shows:
60,41% [kernel] [k] rb_next
9,74% [kernel] [k] btrfs_find_sp
Hi,
Am 16.02.2017 um 11:39 schrieb Stefan Eissing:
>
>> Am 15.02.2017 um 20:53 schrieb Stefan Priebe - Profihost AG
>> :
>>
>> Hi,
>>
>> still no segfaults.
>
> My heart sings with joy. Can you keep on sending that message every morning?
> thank
Hi,
still no segfaults.
@Yann
Are those patches (the addon on top of v7) and the one on top of mod_ssl
still correct / needed?
Stefan
Am 15.02.2017 um 12:45 schrieb Stefan Priebe - Profihost AG:
> Hi,
> Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
>> Hi Stefan,
>>
>> O
Hi,
Am 15.02.2017 um 12:19 schrieb Yann Ylavic:
> Hi Stefan,
>
> On Wed, Feb 15, 2017 at 9:34 AM, Stefan Priebe - Profihost AG
> wrote:
>> Current status: no segfaults.
>
> Is this with or without the mpm_event's wakeup and/or allo
Current status: no segfaults.
Am 14.02.2017 um 19:59 schrieb Stefan Priebe - Profihost AG:
> Hi,
>
> up and running - Thanks!
>
> Greets,
> Stefan
>
> Am 14.02.2017 um 17:05 schrieb Stefan Eissing:
>> Stefan,
>>
>> if you'd like, please throw
I've been testing flashcache, bcache, dm-cache and even dm-writeboost in
production ceph clusters.
The only one that is working fine and gives the speed we need is bcache. All
others failed with slow speeds or low latencies.
Stefan
Excuse my typo sent from my mobile phone.
> Am 15.02.2017 um
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
;
> 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
/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
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
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
To avoid cycling deps an alternative might be forward decleration.
http://www.perlmonks.org/?node_id=1057957
Stefan
Excuse my typo sent from my mobile phone.
Am 06.02.2017 um 18:38 schrieb Dietmar Maurer :
>> An alternative might be
>> http://perldoc.perl.org/autouse.html
>
> Thank for that i
An alternative might be
http://perldoc.perl.org/autouse.html
Stefan
Excuse my typo sent from my mobile phone.
> Am 06.02.2017 um 18:20 schrieb Dietmar Maurer :
>
> is there really no other way to solve this issue?
>
> ___
> pve-devel mailing list
> p
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:
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:
>&
> Reply inline:
>
> On Mon, Feb 06, 2017 at 11:25:44AM +0100, Stefan Priebe - Profihost AG wrote:
>> Hi,
>>
>> after upgrading my test cluster to latest git versions from 4.3. I've no
>> working firewall rules anymore. All chains contain an ACCEPT rule. But
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 :
>>
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,
after upgrading my test cluster to latest git versions from 4.3. I've no
working firewall rules anymore. All chains contain an ACCEPT rule. But
i'm not sure whether this was also the case with 4.3. But it breaks the
rules.
The chains is this one:
# iptables -L tap137i0-IN -vnx
Chain tap137i0-
,
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
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:
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.
>
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
Am 01.02.2017 um 06:36 schrieb Stefan Eissing:
Stefan,
did not have the time to look at it really. Will do, but very busy right now.
Thanks - no problem.
Am 31.01.2017 um 16:01 schrieb Stefan Priebe - Profihost AG
:
Hi Yann,
Hi Stefan,
any ideas?
Stefan
Am 27.01.2017 um 20:30
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
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
>>> :
>>>
: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
>>
>>>
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
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
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
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 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
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 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
>>
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 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 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 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 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 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 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
>>
>
*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
patch again after the
segfaults in 2.4 branch are fixed.
Greets,
Stefan
Am 22.01.2017 um 13:16 schrieb Stefan Priebe:
> Hi,
>
> and a new one but also in ap_start_lingering_close:
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0 apr_palloc (pool=pool@en
thd=) at event.c:1153
#7 worker_thread (thd=0x7f455805e138, dummy=0x20) at event.c:2001
#8 0x7f456b80a0a4 in start_thread ()
from /lib/x86_64-linux-gnu/libpthread.so.0
#9 0x7f456b53f62d in clone () from /lib/x86_64-linux-gnu/libc.so.6
Stefan
Am 21.01.2017 um 19:31 schrieb Stefan Pri
um 19:07 schrieb Stefan Priebe:
Hi Stefan,
thanks. No crashes where h2 comes up. But i still have these and no idea
how to find out who and why they're crashing.
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/local/apache2/bin
improved (hopefully) on them a bit. If you dare to drop that into
your installation, that'd be great.
Cheers,
Stefan
Am 21.01.2017 um 15:25 schrieb Stefan Priebe :
and i got another crash here:
2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
235
ck shortly.
Stefan
Cheers,
Stefan
Am 21.01.2017 um 15:25 schrieb Stefan Priebe :
and i got another crash here:
2346 static void run_cleanups(cleanup_t **cref)
2347 {
2348 cleanup_t *c = *cref;
2349
2350 while (c) {
2351 *cref = c->next;
2352 (*c->plain_clean
(gdb) print *c->data
Attempt to dereference a generic pointer.
(gdb) print *c->plain_cleanup_fn
Cannot access memory at address 0x392d3734322e6369
(gdb)
Stefan
Am 21.01.2017 um 15:18 schrieb Stefan Priebe:
Hi,
#0 apr_pool_cleanup_kill (p=0x7fe4a8072358,
data=data@entry=0x7fe4a80723
= {next = 0x7fe478159628, data = 0x7fe478159648, plain_cleanup_fn =
0x7fe4bbd2ffd0 ,
child_cleanup_fn = 0x7fe4bbd2ff70 }
So p->cleanups->data is 0x7fe478159648 and data is 0x7fe4a80723e0?
I don't get why it's segfaulting
Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:
H
86_64-linux-gnu/libc.so.6
Stefan
Am 21.01.2017 um 09:50 schrieb Yann Ylavic:
Hi Stefan,
On Sat, Jan 21, 2017 at 9:45 AM, Stefan Priebe wrote:
after running the whole night. These are the only ones still happening.
Should i revert the mpm patch to check whether it's the source?
Yes please,
401 - 500 of 3683 matches
Mail list logo
