Re: [VOTE] Release Apache httpd 2.4.10 as GA
On 7/15/2014 10:20 AM, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. Vote will last the normal 72 hrs. +1 various Windows versions/architectures & VC versions
RE: Question about async mod_proxy_wstunnel and threads
OK, I'll have a go at that tomorrow. I should note that it doesn't *always* fail for me. However I haven't yet been able to predict when it will work and when it won't. I did run it earlier with trace7 logging and basically saw no messages for the connections that were stalling. The trunk code I checked out was quite recent, and I did confirm I had all the latest fixes in place. I'll send logs and annotations once I've collected them. Thanks Eric. - Steve From: Eric Covener [cove...@gmail.com] Sent: July 17, 2014 9:15 PM To: Apache HTTP Server Development List Subject: Re: Question about async mod_proxy_wstunnel and threads I am having trouble seeing it mis-behave. w/ Async and AsyncDelay, I am seeing the expected trace messages and when I look at backtraces of httpd I can see zero threads in wstunnel . If I send a server msg, I get it ASAP in the client -- and then I see 1 thread in poll for the right couple of seconds Can you grab trace at e.g. LogLevel INFO proxy_wstunnel_module:trace8 And annotate the timing a bit for what you do in the client? Is it possible you have an un-updated trunk from several weeks ago? There was an optimization put in and backed out that might have broke some of these same things for a very short window. On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote: > Hi > > > > I am prototyping a system in which we will have a large number of websocket > connections between multiple clients and a server (potentially) behind > mod_proxy_wstunnel. Currently I am testing a trunk build with the event mpm. > With ProxyWebsocketAsync turned off, communication between client and server > works well except that an Apache thread is held open for each connection > (which is expected). With ProxyWebsocketAsync enabled, these threads are no > longer seen, again as expected. I see two issues though: > > 1. While communication from client to server works well, unsolicited > messages from the server to clients seem to queue. If the client > subsequently sends a message back to the server, the original message from > the server is received. I would have expected the data from the server to > generate an event resulting in immediate delivery. > > 2. In attempts to debug this I experimented with > ProxyWebsocketAsyncDelay. I observed that when this is used, the connections > never go into async mode. I.e. proxy_tunnel_pump() never returns SUSPENDED. > As a result I see the same thread usage as when ProxyWebsocketAsync is > turned off. Is this expected behavior? > > > > Any insights into what is going on here would be helpful. I noticed that > there have been a number of recent changes both to the event mpm and > mod_proxy_wstunnel. Perhaps there are still some known issues with this > code? > > > > Thanks > > > > - Steve > > > > --- > > Steve Zweep | Senior Software Engineer > > WatchGuard Technologies, Inc. | www.watchguard.com > > > > 905.804.2143 > > steve.zw...@watchguard.com > > -- Eric Covener cove...@gmail.com
Re: Question about async mod_proxy_wstunnel and threads
I am having trouble seeing it mis-behave. w/ Async and AsyncDelay, I am seeing the expected trace messages and when I look at backtraces of httpd I can see zero threads in wstunnel . If I send a server msg, I get it ASAP in the client -- and then I see 1 thread in poll for the right couple of seconds Can you grab trace at e.g. LogLevel INFO proxy_wstunnel_module:trace8 And annotate the timing a bit for what you do in the client? Is it possible you have an un-updated trunk from several weeks ago? There was an optimization put in and backed out that might have broke some of these same things for a very short window. On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote: > Hi > > > > I am prototyping a system in which we will have a large number of websocket > connections between multiple clients and a server (potentially) behind > mod_proxy_wstunnel. Currently I am testing a trunk build with the event mpm. > With ProxyWebsocketAsync turned off, communication between client and server > works well except that an Apache thread is held open for each connection > (which is expected). With ProxyWebsocketAsync enabled, these threads are no > longer seen, again as expected. I see two issues though: > > 1. While communication from client to server works well, unsolicited > messages from the server to clients seem to queue. If the client > subsequently sends a message back to the server, the original message from > the server is received. I would have expected the data from the server to > generate an event resulting in immediate delivery. > > 2. In attempts to debug this I experimented with > ProxyWebsocketAsyncDelay. I observed that when this is used, the connections > never go into async mode. I.e. proxy_tunnel_pump() never returns SUSPENDED. > As a result I see the same thread usage as when ProxyWebsocketAsync is > turned off. Is this expected behavior? > > > > Any insights into what is going on here would be helpful. I noticed that > there have been a number of recent changes both to the event mpm and > mod_proxy_wstunnel. Perhaps there are still some known issues with this > code? > > > > Thanks > > > > - Steve > > > > --- > > Steve Zweep | Senior Software Engineer > > WatchGuard Technologies, Inc. | www.watchguard.com > > > > 905.804.2143 > > steve.zw...@watchguard.com > > -- Eric Covener cove...@gmail.com
Re: [VOTE] Release Apache httpd 2.4.10 as GA
On 15.07.2014 19:20, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 with NetWare.
Re: [VOTE] Release Apache httpd 2.4.10 as GA
On Tue, Jul 15, 2014 at 1:20 PM, Jim Jagielski wrote: > The pre-release test tarballs for Apache httpd 2.4.10 can be found > at the usual place: > > http://httpd.apache.org/dev/dist/ > > I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. > > [ ] +1: Good to go > [ ] +0: meh > [ ] -1: Danger Will Robinson. And why. > > Vote will last the normal 72 hrs. > > NOTE: The *-deps are only there for convenience. > > [X] +1: Good to go WIndows 7/VS 2012 x64 Ubuntu Server 10.04.4 x32
RE: Question about async mod_proxy_wstunnel and threads
It's a bit heavy, but perhaps use PhantomJS as a non-default test? Rick Houser Web Administration (517)367-3516 > -Original Message- > From: Jim Jagielski [mailto:j...@jagunet.com] > Sent: Thursday, July 17, 2014 5:30 PM > To: dev@httpd.apache.org > Subject: Re: Question about async mod_proxy_wstunnel and threads > > If we could figure out someway to get the test framework to > handle tests for websockets, that would be great. My tests > use both node.js and python with simple ws servers, and > it's been hard trying to figure out how to add that kind of > stuff to the framework. :/ > On Jul 17, 2014, at 2:54 PM, Steve Zweep > wrote: > > > Thanks Eric. > > > > BTW, the test setup I have is fairly simple. The websocket server just > > echoes > received messages from any client to all connected clients. I just connect 2 > clients and send a message to the server from one. A tcpdump shows the > correct packets are sent by the server. > > > > - Steve > > > > -Original Message- > > From: Eric Covener [mailto:cove...@gmail.com] > > Sent: Thursday, July 17, 2014 2:27 PM > > To: Apache HTTP Server Development List > > Subject: Re: Question about async mod_proxy_wstunnel and threads > > > > On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep > wrote: > >> 1. While communication from client to server works well, unsolicited > >> messages from the server to clients seem to queue. If the client > >> subsequently sends a message back to the server, the original message > >> from the server is received. I would have expected the data from the > >> server to generate an event resulting in immediate delivery. > > > > your expectation is consistent with mine -- must be a bug. > > > > I don't think my ad-hoc testing had a push like that so it's probably > something small in the managing of the fds -- no reason for it to not be > symmetric > > > >> > >> 2. In attempts to debug this I experimented with > >> ProxyWebsocketAsyncDelay. I observed that when this is used, the > >> connections never go into async mode. I.e. proxy_tunnel_pump() never > returns SUSPENDED. > >> As a result I see the same thread usage as when ProxyWebsocketAsync is > >> turned off. Is this expected behavior? > > > > also not expected > > > >> Any insights into what is going on here would be helpful. I noticed > >> that there have been a number of recent changes both to the event mpm > >> and mod_proxy_wstunnel. Perhaps there are still some known issues with > >> this code? > > > > it is definitely new/rough/experimental and trunk-only. I just added a note > to the docs now. I will try to look this weekend at the two issues above. > > > > -- > > Eric Covener > > cove...@gmail.com
SuexecUserGroup inside Directory context
Hello, The following question hasn’t been answered in the dev list, so I’m trying to ask it again here: http://mail-archives.apache.org/mod_mbox/httpd-dev/201205.mbox/%3cca+-xxsfms0yrmzzitl0x-sgvgzbvxfzvrt57hh163dabrz_...@mail.gmail.com%3E :) Would it be secure to use SuexecUserGroup inside Directory context? And is there any reason why that is still not available? From our point of view, that would provide more security, however, there might have been other technical/security reasons why it is not available/supported yet. I’ve found requests for that in 2005’s https://issues.apache.org/bugzilla/show_bug.cgi?id=37564 and a patch written in 2003 https://www.mail-archive.com/dev@httpd.apache.org/msg17561.html. Thank you for the answers! — Best Regards, Martynas Bendorius
Re: svn commit: r1611252 - /httpd/httpd/trunk/include/util_varbuf.h
Thanks Mike,
Both have been fixed.
CJ
Le 17/07/2014 21:50, Mike Rumph a écrit :
A few comments on typos below:
On 7/16/2014 10:34 PM, jaillet...@apache.org wrote:
Improve layout, add trailing '.' in function description, capitalize
first letter of description, fix typo, turn \0 into \\0.
Move the detailled description after @defgroup so that it is taken
into account.
s/detailled/detailed/
Modified:
httpd/httpd/trunk/include/util_varbuf.h
Modified: httpd/httpd/trunk/include/util_varbuf.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_varbuf.h?rev=1611252&r1=1611251&r2=1611252&view=diff
==
--- httpd/httpd/trunk/include/util_varbuf.h (original)
+++ httpd/httpd/trunk/include/util_varbuf.h Thu Jul 17 05:34:12 2014
@@ -42,87 +43,93 @@ extern "C" {
.
-/** initialize a resizable buffer. It is safe to re-initialize a
prevously
- * used ap_varbuf. The old buffer will be released when the
corresponding
- * pool is cleared. The buffer remains usable until the pool is
cleared,
- * even if the ap_varbuf was located on the stack and has gone out
of scope.
- * @param pool the pool to allocate small buffers from and to
register the
- *cleanup with
- * @param vb pointer to the ap_varbuf struct
- * @param init_size the initial size of the buffer (see
ap_varbuf_grow() for details)
+/**
+ * Initialize a resizable buffer. It is safe to re-initialize a
prevously
s/prevously/previously/
+ * used ap_varbuf. The old buffer will be released when the
corresponding
+ * pool is cleared. The buffer remains usable until the pool is
cleared,
+ * even if the ap_varbuf was located on the stack and has gone out
of scope.
+ * @param poolThe pool to allocate small buffers from and
to register
+ * the cleanup with
+ * @param vb Pointer to the ap_varbuf struct
+ * @param init_size The initial size of the buffer (see
ap_varbuf_grow() for
+ * details)
*/
AP_DECLARE(void) ap_varbuf_init(apr_pool_t *pool, struct ap_varbuf
*vb,
apr_size_t init_size);
Re: Question about async mod_proxy_wstunnel and threads
If we could figure out someway to get the test framework to handle tests for websockets, that would be great. My tests use both node.js and python with simple ws servers, and it's been hard trying to figure out how to add that kind of stuff to the framework. :/ On Jul 17, 2014, at 2:54 PM, Steve Zweep wrote: > Thanks Eric. > > BTW, the test setup I have is fairly simple. The websocket server just echoes > received messages from any client to all connected clients. I just connect 2 > clients and send a message to the server from one. A tcpdump shows the > correct packets are sent by the server. > > - Steve > > -Original Message- > From: Eric Covener [mailto:cove...@gmail.com] > Sent: Thursday, July 17, 2014 2:27 PM > To: Apache HTTP Server Development List > Subject: Re: Question about async mod_proxy_wstunnel and threads > > On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep > wrote: >> 1. While communication from client to server works well, unsolicited >> messages from the server to clients seem to queue. If the client >> subsequently sends a message back to the server, the original message >> from the server is received. I would have expected the data from the >> server to generate an event resulting in immediate delivery. > > your expectation is consistent with mine -- must be a bug. > > I don't think my ad-hoc testing had a push like that so it's probably > something small in the managing of the fds -- no reason for it to not be > symmetric > >> >> 2. In attempts to debug this I experimented with >> ProxyWebsocketAsyncDelay. I observed that when this is used, the >> connections never go into async mode. I.e. proxy_tunnel_pump() never returns >> SUSPENDED. >> As a result I see the same thread usage as when ProxyWebsocketAsync is >> turned off. Is this expected behavior? > > also not expected > >> Any insights into what is going on here would be helpful. I noticed >> that there have been a number of recent changes both to the event mpm >> and mod_proxy_wstunnel. Perhaps there are still some known issues with >> this code? > > it is definitely new/rough/experimental and trunk-only. I just added a note > to the docs now. I will try to look this weekend at the two issues above. > > -- > Eric Covener > cove...@gmail.com
Re: svn commit: r1611252 - /httpd/httpd/trunk/include/util_varbuf.h
A few comments on typos below:
On 7/16/2014 10:34 PM, jaillet...@apache.org wrote:
Improve layout, add trailing '.' in function description, capitalize first
letter of description, fix typo, turn \0 into \\0.
Move the detailled description after @defgroup so that it is taken into account.
s/detailled/detailed/
Modified:
httpd/httpd/trunk/include/util_varbuf.h
Modified: httpd/httpd/trunk/include/util_varbuf.h
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/util_varbuf.h?rev=1611252&r1=1611251&r2=1611252&view=diff
==
--- httpd/httpd/trunk/include/util_varbuf.h (original)
+++ httpd/httpd/trunk/include/util_varbuf.h Thu Jul 17 05:34:12 2014
@@ -42,87 +43,93 @@ extern "C" {
.
-/** initialize a resizable buffer. It is safe to re-initialize a prevously
- * used ap_varbuf. The old buffer will be released when the corresponding
- * pool is cleared. The buffer remains usable until the pool is cleared,
- * even if the ap_varbuf was located on the stack and has gone out of scope.
- * @param pool the pool to allocate small buffers from and to register the
- *cleanup with
- * @param vb pointer to the ap_varbuf struct
- * @param init_size the initial size of the buffer (see ap_varbuf_grow() for
details)
+/**
+ * Initialize a resizable buffer. It is safe to re-initialize a prevously
s/prevously/previously/
+ * used ap_varbuf. The old buffer will be released when the corresponding
+ * pool is cleared. The buffer remains usable until the pool is cleared,
+ * even if the ap_varbuf was located on the stack and has gone out of scope.
+ * @param poolThe pool to allocate small buffers from and to register
+ * the cleanup with
+ * @param vb Pointer to the ap_varbuf struct
+ * @param init_size The initial size of the buffer (see ap_varbuf_grow()
for
+ * details)
*/
AP_DECLARE(void) ap_varbuf_init(apr_pool_t *pool, struct ap_varbuf *vb,
apr_size_t init_size);
RE: Question about async mod_proxy_wstunnel and threads
Thanks Eric. BTW, the test setup I have is fairly simple. The websocket server just echoes received messages from any client to all connected clients. I just connect 2 clients and send a message to the server from one. A tcpdump shows the correct packets are sent by the server. - Steve -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Thursday, July 17, 2014 2:27 PM To: Apache HTTP Server Development List Subject: Re: Question about async mod_proxy_wstunnel and threads On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote: > 1. While communication from client to server works well, unsolicited > messages from the server to clients seem to queue. If the client > subsequently sends a message back to the server, the original message > from the server is received. I would have expected the data from the > server to generate an event resulting in immediate delivery. your expectation is consistent with mine -- must be a bug. I don't think my ad-hoc testing had a push like that so it's probably something small in the managing of the fds -- no reason for it to not be symmetric > > 2. In attempts to debug this I experimented with > ProxyWebsocketAsyncDelay. I observed that when this is used, the > connections never go into async mode. I.e. proxy_tunnel_pump() never returns > SUSPENDED. > As a result I see the same thread usage as when ProxyWebsocketAsync is > turned off. Is this expected behavior? also not expected > Any insights into what is going on here would be helpful. I noticed > that there have been a number of recent changes both to the event mpm > and mod_proxy_wstunnel. Perhaps there are still some known issues with > this code? it is definitely new/rough/experimental and trunk-only. I just added a note to the docs now. I will try to look this weekend at the two issues above. -- Eric Covener cove...@gmail.com
Re: Question about async mod_proxy_wstunnel and threads
On Thu, Jul 17, 2014 at 2:09 PM, Steve Zweep wrote: > 1. While communication from client to server works well, unsolicited > messages from the server to clients seem to queue. If the client > subsequently sends a message back to the server, the original message from > the server is received. I would have expected the data from the server to > generate an event resulting in immediate delivery. your expectation is consistent with mine -- must be a bug. I don't think my ad-hoc testing had a push like that so it's probably something small in the managing of the fds -- no reason for it to not be symmetric > > 2. In attempts to debug this I experimented with > ProxyWebsocketAsyncDelay. I observed that when this is used, the connections > never go into async mode. I.e. proxy_tunnel_pump() never returns SUSPENDED. > As a result I see the same thread usage as when ProxyWebsocketAsync is > turned off. Is this expected behavior? also not expected > Any insights into what is going on here would be helpful. I noticed that > there have been a number of recent changes both to the event mpm and > mod_proxy_wstunnel. Perhaps there are still some known issues with this > code? it is definitely new/rough/experimental and trunk-only. I just added a note to the docs now. I will try to look this weekend at the two issues above. -- Eric Covener cove...@gmail.com
Question about async mod_proxy_wstunnel and threads
Hi I am prototyping a system in which we will have a large number of websocket connections between multiple clients and a server (potentially) behind mod_proxy_wstunnel. Currently I am testing a trunk build with the event mpm. With ProxyWebsocketAsync turned off, communication between client and server works well except that an Apache thread is held open for each connection (which is expected). With ProxyWebsocketAsync enabled, these threads are no longer seen, again as expected. I see two issues though: 1. While communication from client to server works well, unsolicited messages from the server to clients seem to queue. If the client subsequently sends a message back to the server, the original message from the server is received. I would have expected the data from the server to generate an event resulting in immediate delivery. 2. In attempts to debug this I experimented with ProxyWebsocketAsyncDelay. I observed that when this is used, the connections never go into async mode. I.e. proxy_tunnel_pump() never returns SUSPENDED. As a result I see the same thread usage as when ProxyWebsocketAsync is turned off. Is this expected behavior? Any insights into what is going on here would be helpful. I noticed that there have been a number of recent changes both to the event mpm and mod_proxy_wstunnel. Perhaps there are still some known issues with this code? Thanks - Steve --- Steve Zweep | Senior Software Engineer WatchGuard Technologies, Inc. | www.watchguard.com 905.804.2143 steve.zw...@watchguard.com
Re: [VOTE] Release Apache httpd 2.4.10 as GA
And +1 on FreeBSD9 and FreeBSD10 (no regressions) FreeBSD freebsd9.localdomain 9.2-RELEASE-p10 FreeBSD 9.2-RELEASE-p10 #0: Tue Jul 8 10:48:24 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD freebsd10.localdomain 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Tue Jul 8 06:37:44 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 On Jul 15, 2014, at 2:46 PM, Jim Jagielski wrote: > Testing Linux and OSX 1st (all using Event MPM): > > So far, +1 on all the below: > > CentOS 7 >Linux centos7.localdomain 3.10.0-123.4.2.el7.x86_64 #1 SMP Mon Jun 30 > 16:09:14 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > OSX 10.9.4 / Xcode 5.1.1 >Darwin jimsys 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT > 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64 > > CentOS 6 >Linux centos6.localdomain 2.6.32-431.17.1.el6.x86_64 #1 SMP Wed May 7 > 23:32:49 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux > > CentOS 5 >Linux centos5.localdomain 2.6.18-371.9.1.el5 #1 SMP Tue Jun 10 17:49:56 > EDT 2014 x86_64 x86_64 x86_64 GNU/Linux > > > FreeBSD coming up. > > On Jul 15, 2014, at 1:20 PM, Jim Jagielski wrote: > >> The pre-release test tarballs for Apache httpd 2.4.10 can be found >> at the usual place: >> >> http://httpd.apache.org/dev/dist/ >> >> I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. >> >> [ ] +1: Good to go >> [ ] +0: meh >> [ ] -1: Danger Will Robinson. And why. >> >> Vote will last the normal 72 hrs. >> >> NOTE: The *-deps are only there for convenience. >> >
Re: Apache2 crashes with segmentation fault
Since you don't say what version of mod_wsgi you are using, or what version
of Apache, then the only other thing I can suggest right now is to ensure
that you are using the latest mod_wsgi version.
The latest version of mod_wsgi is version 4.2.6. Pretty well all Linux
distributions are still shipping version 3.3.
Older versions may exhibit segmentation faults with Apache 2.4 in some
situations, although this is generally only on process shutdown and I have
never heard of mod_wsgi itself to cause a hang when using Apache 2.4,
although lxml is very much known to in some cases.
Either way, please take this discussion now to the mod_wsgi mailing list as
described in the mod_wsgi documentation.
http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6#Asking_Your_Questions
When you post to the mod_wsgi mailing list, please provide proper Apache
and mod_wsgi version details as described in:
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Build_Information
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Apache_Modules_Loaded
As well as results of verifying Python installation in use:
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use
and confirmation that your application is indeed running in the main
interpreter and daemon mode.
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Embedded_Or_Daemon_Mode
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Sub_Interpreter_Being_Used
See you in the mod_wsgi mailing list.
Graham
On 17 July 2014 01:32, Elhadi Falah wrote:
> Hello,
>
> I use mod_wsgi to run processes and not mod_python.
>
> WSGIDaemonProcess p1 threads=25
> python-path=/opt/appengine/google_appengine:/opt/appengine/google_appengine/lib/django:/opt/appengine/google_appengine/lib/webob:/opt/appengine/google_appengine/lib/yaml/lib
> WSGIProcessGroup p1
>
> WSGIScriptAlias / /var/www/application/rep/handler.wsgi
>
> I already used the directive WSGIApplicationGroup %{GLOBAL} to run un the
> main interpreter context but the issue persists after executing apache
> graceful or reload.
>
> Regards
>
>
>
> 2014-07-16 13:44 GMT+00:00 Graham Dumpleton :
>
> It is well known that the lxml package doesn't work properly in a Python
>> sub interpreter context. Force it to run in the main interpreter context.
>>
>> See:
>>
>>
>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>>
>> In other words look at using:
>>
>> WSGIApplicationGroup %{GLOBAL}
>>
>> as documented.
>>
>> Graham
>>
>>
>> On 16 July 2014 03:11, Elhadi Falah wrote:
>>
>>> Hello,
>>>
>>> We are using lxml in several of our applications with Python 2.6 and
>>> from time to time, the application stops responding after a segmentation
>>> fault error ( [notice] child pid 10544 exit signal Segmentation fault
>>> (11)), and this kind of backtrace:
>>>
>>> Jul 1 15:24:48 server1 httpd: *** glibc detected *** /usr/sbin/apache2:
>>> munmap_chunk(): invalid pointer: 0x7f6468bf2c00 ***
>>>
>>> Jul 1 15:24:48 server1 httpd: === Backtrace: =
>>>
>>> Jul 1 15:24:48 server1 httpd: /lib/libc.so.6(+0x78bf6)[0x7f64767ecbf6]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/libxml2.so.2(xmlCopyError+0xd1)[0x7f6473311801]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/libxml2.so.2(__xmlRaiseError+0x30b)[0x7f6473312ecb]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/libxml2.so.2(+0x393e5)[0x7f64733173e5]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/libxml2.so.2(xmlParseDocument+0x2dc)[0x7f647332e5cc]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/libxml2.so.2(+0x50895)[0x7f647332e895]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8cbc2)[0x7f645691cbc2]
>>>
>>> Jul 1 15:24:48 server1 httpd:
>>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2c7cf)[0x7f64568bc7cf]
>>>
>>> After trying several versions of lxml we are still facing the issue.I've
>>> checked for the system memory consumption but everything looks fine to me,
>>> plenty of memory available, I don't see any process consuming abnormally.
>>>
>>> The issue is reproducible everytime when we execute the commande apache
>>> (apache2 reload or apache2 graceful). As workaround for this issue we
>>> execute apache2 restart.
>>>
>>> We've followed recommendations defined on these 2 links but we're still
>>> facing the issue.
>>>
>>>
>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>>>
>>>
>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters
>>>
>>> Library version:
>>>
>>>print("%-20s: %s" % ('Python', sys.version_info))
>>>
>>> Python : (2, 6, 5, 'final', 0)
>>>
>>>print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION))
>>>
>>> lxml.etree : (2, 3, 5, 0)
>>>
>>>print(
Re: [VOTE] Release Apache httpd 2.4.10 as GA
On 16/07/2014 03:20, Jim Jagielski wrote: The pre-release test tarballs for Apache httpd 2.4.10 can be found at the usual place: http://httpd.apache.org/dev/dist/ I'm calling a VOTE on releasing these as Apache httpd 2.4.10 GA. [ ] +1: Good to go [ ] +0: meh [ ] -1: Danger Will Robinson. And why. +1 slackware (w/APR 1.5.1, APR-util 1.5.3) 13.1, 14.0, 14.1
Re: Apache2 crashes with segmentation fault
Hello,
I use mod_wsgi to run processes and not mod_python.
WSGIDaemonProcess p1 threads=25
python-path=/opt/appengine/google_appengine:/opt/appengine/google_appengine/lib/django:/opt/appengine/google_appengine/lib/webob:/opt/appengine/google_appengine/lib/yaml/lib
WSGIProcessGroup p1
WSGIScriptAlias / /var/www/application/rep/handler.wsgi
I already used the directive WSGIApplicationGroup %{GLOBAL} to run un the
main interpreter context but the issue persists after executing apache
graceful or reload.
Regards
2014-07-16 13:44 GMT+00:00 Graham Dumpleton :
> It is well known that the lxml package doesn't work properly in a Python
> sub interpreter context. Force it to run in the main interpreter context.
>
> See:
>
>
> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>
> In other words look at using:
>
> WSGIApplicationGroup %{GLOBAL}
>
> as documented.
>
> Graham
>
>
> On 16 July 2014 03:11, Elhadi Falah wrote:
>
>> Hello,
>>
>> We are using lxml in several of our applications with Python 2.6 and from
>> time to time, the application stops responding after a segmentation fault
>> error ( [notice] child pid 10544 exit signal Segmentation fault (11)), and
>> this kind of backtrace:
>>
>> Jul 1 15:24:48 server1 httpd: *** glibc detected *** /usr/sbin/apache2:
>> munmap_chunk(): invalid pointer: 0x7f6468bf2c00 ***
>>
>> Jul 1 15:24:48 server1 httpd: === Backtrace: =
>>
>> Jul 1 15:24:48 server1 httpd: /lib/libc.so.6(+0x78bf6)[0x7f64767ecbf6]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/libxml2.so.2(xmlCopyError+0xd1)[0x7f6473311801]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/libxml2.so.2(__xmlRaiseError+0x30b)[0x7f6473312ecb]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/libxml2.so.2(+0x393e5)[0x7f64733173e5]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/libxml2.so.2(xmlParseDocument+0x2dc)[0x7f647332e5cc]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/libxml2.so.2(+0x50895)[0x7f647332e895]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x8cbc2)[0x7f645691cbc2]
>>
>> Jul 1 15:24:48 server1 httpd:
>> /usr/lib/python2.6/dist-packages/lxml/etree.so(+0x2c7cf)[0x7f64568bc7cf]
>>
>> After trying several versions of lxml we are still facing the issue.I've
>> checked for the system memory consumption but everything looks fine to me,
>> plenty of memory available, I don't see any process consuming abnormally.
>>
>> The issue is reproducible everytime when we execute the commande apache
>> (apache2 reload or apache2 graceful). As workaround for this issue we
>> execute apache2 restart.
>>
>> We've followed recommendations defined on these 2 links but we're still
>> facing the issue.
>>
>>
>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
>>
>>
>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Multiple_Python_Sub_Interpreters
>>
>> Library version:
>>
>>print("%-20s: %s" % ('Python', sys.version_info))
>>
>> Python : (2, 6, 5, 'final', 0)
>>
>>print("%-20s: %s" % ('lxml.etree', etree.LXML_VERSION))
>>
>> lxml.etree : (2, 3, 5, 0)
>>
>>print("%-20s: %s" % ('libxml used', etree.LIBXML_VERSION))
>>
>> libxml used : (2, 7, 6)
>>
>>print("%-20s: %s" % ('libxml compiled',
>> etree.LIBXML_COMPILED_VERSION))
>>
>> libxml compiled : (2, 7, 6)
>>
>>print("%-20s: %s" % ('libxslt used', etree.LIBXSLT_VERSION))
>>
>> libxslt used: (1, 1, 26)
>>
>>print("%-20s: %s" % ('libxslt compiled',
>> etree.LIBXSLT_COMPILED_VERSION))
>>
>> libxslt compiled: (1, 1, 26)
>>
>> Apache 2.2.14
>>
>> Here is the source code that generate the issue:
>>
>> ID_TRANSFORM =
>> os.environ['APPLICATION_WORKING_PATH']+'/statics/xsl/list.xsl'
>>
>> styledoc = lxml.etree.parse(ID_TRANSFORM)
>>
>> transform = lxml.etree.XSLT(styledoc)
>>
>> doc_root = lxml.etree.XML(str(atom))
>>
>> Could you help us on this case?
>>
>> Regards
>>
>>
>
