Unfortunately i still get the Segmentation fault (11), i managed to get the apache to core dump every time it gets the fault.
Would it help you more if you had the analysis from the core ??? Can you see something in there that can help? In general the current situation apart from the Seg faults is that i am getting the OperationalError: ORA-03114: not connected to ORACLE so the application is not working... Alex On Tuesday, March 10, 2015 at 12:03:08 PM UTC+2, Graham Dumpleton wrote: > > I wasn't so concerned about the fact the Apache generated header files > were busted. There isn't much I can do about that. > > More important is whether the compiled binary worked for you. I didn't > hear anything more from you to say it didn't so had assumed it was working > okay. > > What is the current situation? > > Graham > > On 10/03/2015, at 9:01 PM, [email protected] <javascript:> wrote: > > Hi Graham, > > Do you need me to send you any of those files to have a better look ? > > Regards, > Alex > > On Friday, March 6, 2015 at 1:56:32 PM UTC+2, [email protected] > wrote: >> >> Disabling the specific lines as you suggested worked i was able to >> compile it. >> >> Also i performed the grep >> >> >> oracle@serpa:[/opt/webtier/Middleware]#/usr/sfw/bin/ggrep -r >> HAVE_SYS_PRCTL_H * >> Oracle_WT1/ohs/include/ap_config_auto.h:/* #undef HAVE_SYS_PRCTL_H */ >> Oracle_WT1/ohs/include/ap_config_auto.h:#define HAVE_SYS_PRCTL_H 1 >> oracle@serpa:[/opt/webtier/Middleware]# >> >> >> >> >> On Friday, March 6, 2015 at 1:35:16 PM UTC+2, Graham Dumpleton wrote: >>> >>> Looks like it is Apache that might have the wrong definition for that >>> symbol. >>> >>> For example on MacOS X: >>> >>> $ grep HAVE_SYS_PRCTL_H /usr/include/apache2/*.h >>> /usr/include/apache2/ap_config_auto.h:/* #undef HAVE_SYS_PRCTL_H */ >>> >>> I suspect the header file is only meant to exist on Linux. So may not >>> relate to OS version. >>> >>> If you can find where the Apache header files are installed and grep for >>> that name and see whether has #define or whether is a comment out #undef, >>> would tell you whether that is the origin. >>> >>> Graham >>> >>> On 06/03/2015, at 10:30 PM, Graham Dumpleton <[email protected]> >>> wrote: >>> >>> If you are getting: >>> >>> "src/server/mod_wsgi.c", line 25: cannot find include file: >>> <sys/prctl.h> >>> >>> there is something broken with your Apache installation, or maybe Python >>> installation. >>> >>> That would only be included if either Apache or Python said that header >>> file existed. >>> >>> #ifdef HAVE_SYS_PRCTL_H >>> #include <sys/prctl.h> >>> #endif >>> >>> What might be the issue is that either Apache or Python was originally >>> built on an older OS revision where that header file existed but your newer >>> system doesn't have it. >>> >>> I would suggest editing mod_wsgi.c file and change and disable the use >>> of those lines: >>> >>> #if 0 >>> #ifdef HAVE_SYS_PRCTL_H >>> #include <sys/prctl.h> >>> #endif >>> #endif >>> >>> Graham >>> >>> On 06/03/2015, at 9:55 PM, [email protected] wrote: >>> >>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]#./configure >>> --with-apxs=/opt/webtier/Middleware/Oracle_WT1/ohs/bin/apxs >>> --with-python=/opt/webtier/python_64/bin/python >>> apxs:Error: Invalid query string `LIBTOOL' >>> checking for gcc... gcc >>> checking whether the C compiler works... yes >>> checking for C compiler default output file name... a.out >>> checking for suffix of executables... >>> checking whether we are cross compiling... no >>> checking for suffix of object files... o >>> checking whether we are using the GNU C compiler... yes >>> checking whether gcc accepts -g... yes >>> checking for gcc option to accept ISO C89... none needed >>> checking for prctl... no >>> checking Apache version... 2.2.22 >>> configure: creating ./config.status >>> config.status: creating Makefile >>> >>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]#LD_RUN_PATH=/opt/webtier/python_64/lib >>> >>> make >>> /opt/webtier/Middleware/Oracle_WT1/ohs/bin/apxs -c >>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG -Wc,-g -Wc,-O2 >>> src/server/mod_wsgi.c src/server/wsgi_*.c -L/opt/webtier/python_64/lib >>> -L/opt/webtier/python_64/lib/python2.6/config -lpython2.6 -lsocket -lnsl >>> -lrt -ldl -lm >>> /opt/webtier/Middleware/Oracle_WT1/ohs/build/libtool --tag=CC >>> --mode=compile cc -O -DNO_RC2 -DNO_RC5 -DNO_IDEA -DBSAFE -fPIC -m64 >>> -DLINUX=260 -DMOD_SSL=206104 -DMOD_PERL -DUSE_PERL_SSI -I/include -DEAPI >>> -D_LARGEFILE64_SOURCE -DUSE_EXPAT -I../lib/expat-lite >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include -g -O2 >>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG -c -o >>> src/server/mod_wsgi.lo src/server/mod_wsgi.c && touch >>> src/server/mod_wsgi.slo >>> mkdir src/server/.libs >>> cc -O -DNO_RC2 -DNO_RC5 -DNO_IDEA -DBSAFE -fPIC -m64 -DLINUX=260 >>> -DMOD_SSL=206104 -DMOD_PERL -DUSE_PERL_SSI -I/include -DEAPI >>> -D_LARGEFILE64_SOURCE -DUSE_EXPAT -I../lib/expat-lite >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include >>> -I/opt/webtier/Middleware/Oracle_WT1/ohs/include -g -O2 >>> -I/opt/webtier/python_64/include/python2.6 -DNDEBUG -c >>> src/server/mod_wsgi.c -KPIC -DPIC -o src/server/.libs/mod_wsgi.o >>> "src/server/mod_wsgi.c", line 25: cannot find include file: <sys/prctl.h> >>> "src/server/mod_wsgi.c", line 8357: warning: statement not reached >>> "src/server/mod_wsgi.c", line 8540: warning: statement not reached >>> "src/server/mod_wsgi.c", line 10364: warning: statement not reached >>> cc: acomp failed for src/server/mod_wsgi.c >>> apxs:Error: Command failed with rc=65536 >>> . >>> *** Error code 1 >>> make: Fatal error: Command failed for target `src/server/mod_wsgi.la' >>> oracle@serpa:[/opt/media/mod_wsgi-4.4.9]# >>> >>> >>> >>> >>> >>> On Friday, March 6, 2015 at 12:45:18 PM UTC+2, Graham Dumpleton wrote: >>>> >>>> >>>> On 06/03/2015, at 9:20 PM, [email protected] wrote: >>>> >>>> Sorry Graham my mistake the mod_wsgi i am using is 3.2 which i had to >>>> compile myself, i downloaded the source code and did the compile. I am on >>>> a >>>> Solaris 10 and for web server i am using Oracle OHS (Oracle HTTP Server). >>>> >>>> The problem is that i am having issues with compiling the latest >>>> version of mod_wsgi in my solaris. >>>> >>>> Can you help me with that ?? >>>> >>>> >>>> Sure, what is the specific problem/error with the very latest mod_wsgi >>>> version? >>>> >>>> Graham >>>> >>>> On Friday, March 6, 2015 at 12:09:47 PM UTC+2, Graham Dumpleton wrote: >>>>> >>>>> Do you really mean 3.1.2, or perhaps 3.1 where some OS distribution is >>>>> tagging on a '-2' qualifier? >>>>> >>>>> Although there was a version 3.1, there never was a 3.1.2 as I only >>>>> started using 3 part version numbers with 4.1.0. >>>>> >>>>> If it is 3.1, which if it is Oracle Linux I wouldn't be surprised, >>>>> then it was released 4 1/2 years ago and is way out of date. >>>>> >>>>> Is there any chance at all you can upgrade to a recent version of >>>>> mod_wsgi by compiling from mod_wsgi source code yourself? >>>>> >>>>> In using such an old version of mod_wsgi I am not sure there is much I >>>>> can do to help you. If it is an issue which was since fixed, you wouldn't >>>>> have much choice but to upgrade anyway. >>>>> >>>>> Graham >>>>> >>>>> On 06/03/2015, at 2:02 AM, [email protected] wrote: >>>>> >>>>> Server version: Oracle-HTTP-Server/2.2.22 >>>>> >>>>> mod_wsgi: 3.1.2 >>>>> >>>>> Can this be the cause of the DB errors i am getting i.e. the process >>>>> is crashing and with it together the DB connection ???? >>>>> >>>>> Regards, >>>>> Alex >>>>> >>>>> >>>>> >>>>> On Thursday, March 5, 2015 at 12:46:23 PM UTC+2, Graham Dumpleton >>>>> wrote: >>>>>> >>>>>> What version of mod_wsgi are you using? >>>>>> >>>>>> What patch level revision of Apache are you using? >>>>>> >>>>>> The crash of first daemon process instance but not subsequent ones >>>>>> sounds a bit like a bug I fixed not long back. >>>>>> >>>>>> I can't right now remember what the issue was and can't find any note >>>>>> about it in release notes for 4.4.X versions. >>>>>> >>>>>> Graham >>>>>> >>>>>> On 04/03/2015, at 10:47 PM, [email protected] wrote: >>>>>> >>>>>> Shouldn't this cause a core dump ?? Because i can not find any in >>>>>> order to analyze it.... >>>>>> >>>>>> On Wednesday, March 4, 2015 at 1:36:45 PM UTC+2, alexandros...@ >>>>>> gmail.com wrote: >>>>>>> >>>>>>> Yes i tried it and the same thing happens: >>>>>>> >>>>>>> [Wed Mar 04 13:31:53 2015] [notice] child pid 10101 exit signal >>>>>>> Segmentation fault (11) >>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1818): proxy: >>>>>>> grabbed scoreboard slot 0 in child 10148 for worker proxy:reverse >>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1837): proxy: worker >>>>>>> proxy:reverse already initialized >>>>>>> [Wed Mar 04 13:31:54 2015] [debug] proxy_util.c(1914): proxy: >>>>>>> initialized worker 0 in child 10148 for (*) min=0 max=25 smax=25 >>>>>>> [Wed Mar 04 13:31:54 2015] [info] mod_wsgi (pid=10148): Initializing >>>>>>> Python. >>>>>>> [Wed Mar 04 13:31:54 2015] [info] mod_wsgi (pid=10148): Attach >>>>>>> interpreter ''. >>>>>>> >>>>>>> It crashes the first interpreter and its attaching a new one... >>>>>>> >>>>>>> On Wednesday, March 4, 2015 at 12:42:32 PM UTC+2, Graham Dumpleton >>>>>>> wrote: >>>>>>>> >>>>>>>> Are you setting: >>>>>>>> >>>>>>>> WSGIApplicationGroup %{GLOBAL} >>>>>>>> >>>>>>>> directive. >>>>>>>> >>>>>>>> >>>>>>>> http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API >>>>>>>> >>>>>>>> That is often a good remedy for process crashes when using Python >>>>>>>> third party extensions modules which aren't implemented properly to >>>>>>>> work in >>>>>>>> sub interpreters. >>>>>>>> >>>>>>>> Graham >>>>>>>> >>>>>>>> On 04/03/2015, at 9:25 PM, [email protected] wrote: >>>>>>>> >>>>>>>> Also from the logs its seems that there are some Segmentation >>>>>>>> faults >>>>>>>> >>>>>>>> mod_wsgi (pid=9760): Create interpreter >>>>>>>> ........ >>>>>>>> >>>>>>>> child pid 9760 exit signal Segmentation fault (11) >>>>>>>> >>>>>>>> Is this normal ??? >>>>>>>> >>>>>>>> On Monday, March 2, 2015 at 12:39:02 PM UTC+2, alexandros...@ >>>>>>>> gmail.com wrote: >>>>>>>>> >>>>>>>>> Hi Graham, >>>>>>>>> >>>>>>>>> In my project i already have *DEBUG = True* which i think it >>>>>>>>> overwrites global settings. >>>>>>>>> >>>>>>>>> Is DEBUG = True enough to force Django to log details of unhanded >>>>>>>>> exceptions?? Or should i do anything else? >>>>>>>>> >>>>>>>>> I already have print outs of os.environ and i have checked that >>>>>>>>> ORACLE_HOME and TNS_ADMIN is set to the correct paths , i think that >>>>>>>>> those >>>>>>>>> are the only 2 variables needed for ORACLE... If i am wrong please >>>>>>>>> correct >>>>>>>>> me. >>>>>>>>> >>>>>>>>> I do not know what else should i do in order to get to log all the >>>>>>>>> exceptions in the logs.... >>>>>>>>> >>>>>>>>> But i think this is like the other case you help me solve with >>>>>>>>> "hashlib"... The true problem/exception was never logged, until you >>>>>>>>> told me >>>>>>>>> to try to import _hashlib instead of hashlib. THEN AND OLNY then the >>>>>>>>> problem was clear and i was able to fix it. I think that the same >>>>>>>>> circumstances apply here... Somehow i am not getting the real >>>>>>>>> issue... >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> On Friday, February 27, 2015 at 11:47:28 PM UTC+2, Graham >>>>>>>>> Dumpleton wrote: >>>>>>>>>> >>>>>>>>>> If this is only the latter consequence, then have you got Django >>>>>>>>>> setup to send you details of unhanded exceptions in emails or >>>>>>>>>> otherwise log >>>>>>>>>> them. If you don't then Django will simply translate an error into a >>>>>>>>>> generic 500 response page and you will not see the error anywhere. >>>>>>>>>> >>>>>>>>>> If you are on a development system, you can alternatively enable >>>>>>>>>> temporarily in the Django settings file: >>>>>>>>>> >>>>>>>>>> DEBUG = True >>>>>>>>>> >>>>>>>>>> and if it was creating a 500 page then it will then include the >>>>>>>>>> exception details that caused it. >>>>>>>>>> >>>>>>>>>> BTW other possible problems with Oracle specifically are missing >>>>>>>>>> ORACLE_??? environment variables set in environment of Apache. >>>>>>>>>> >>>>>>>>>> If you add debug statements in WSGI script file to print out >>>>>>>>>> contents of os.environ from 'os' module, dod you see all the >>>>>>>>>> ORACLE_?? >>>>>>>>>> environment variables you expect to see that might be set in the >>>>>>>>>> shell of >>>>>>>>>> your user environment. >>>>>>>>>> >>>>>>>>>> Graham >>>>>>>>>> >>>>>>>>>> On 28/02/2015, at 8:40 AM, [email protected] wrote: >>>>>>>>>> >>>>>>>>>> Hi Graham, >>>>>>>>>> >>>>>>>>>> Can you elaborate more on this... Based on the Django project i >>>>>>>>>> have created, in the settings for the Oracle DB i have provided the >>>>>>>>>> user >>>>>>>>>> (db schema) the application should use to connect to the db. >>>>>>>>>> >>>>>>>>>> I have not changed anything since i migrated the project to the >>>>>>>>>> new infrastructure and the project was working fine before. I am on >>>>>>>>>> the >>>>>>>>>> same machine i just installed everything again basically.. >>>>>>>>>> >>>>>>>>>> I know that somewhere there is an exception occurring, but the >>>>>>>>>> problem is that it is never caught and printed in the logs.... >>>>>>>>>> >>>>>>>>>> As you can see in the logs the only errors are when it tries to >>>>>>>>>> close the connection and most probably never finds one.. either >>>>>>>>>> because it >>>>>>>>>> was never created or it is closed before everything else is >>>>>>>>>> executed. >>>>>>>>>> >>>>>>>>>> I want to find a way to debug this ... Is there a way to trace >>>>>>>>>> each call and every step so i can place some sort of print to see >>>>>>>>>> where the >>>>>>>>>> code is not working ... Because i do not know any other way to fix >>>>>>>>>> this. >>>>>>>>>> >>>>>>>>>> I another problem i had, you were the one that suggested >>>>>>>>>> something that relieved the actual problem and i was able to fix it, >>>>>>>>>> because before that the only errors in the logs i was seeing were >>>>>>>>>> not >>>>>>>>>> relevant to the problem. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> >>>>>>>>>> On Thursday, February 26, 2015 at 11:42:26 AM UTC+2, Graham >>>>>>>>>> Dumpleton wrote: >>>>>>>>>>> >>>>>>>>>>> If Oracle is providing access based on the identity of the user >>>>>>>>>>> connecting though local UNIX socket connection to the database, it >>>>>>>>>>> could be >>>>>>>>>>> failing because your application will be running as the Apache user >>>>>>>>>>> and >>>>>>>>>>> maybe you haven't configured Oracle to allow that user to connect. >>>>>>>>>>> >>>>>>>>>>> Graham >>>>>>>>>>> >>>>>>>>>>> On 25/02/2015, at 10:09 PM, [email protected] wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I migrated my project to a new infrastructure but i kept the >>>>>>>>>>> same versions Apache 2.2 + mod_wsgi + python 2.6.1 + Django 1.2.1 + >>>>>>>>>>> ....... >>>>>>>>>>> >>>>>>>>>>> I am trying to run my project or even access the admin console >>>>>>>>>>> of Django /admin and i can not. >>>>>>>>>>> >>>>>>>>>>> I tried to connect directly from the Oracle Client (sqlplus) and >>>>>>>>>>> i can, i created a simple python script that uses cx_oracle and i >>>>>>>>>>> am able >>>>>>>>>>> to connect to the database without any problems, i have tested >>>>>>>>>>> "python >>>>>>>>>>> manage.py dbshell" and it connects. I also used "python manage.py >>>>>>>>>>> runserver" and by navigating to http://127.0.0.1:8000/admin i >>>>>>>>>>> was able to access the console without any errors, but when i try >>>>>>>>>>> using >>>>>>>>>>> apache + mod_wsgi i get the following error: >>>>>>>>>>> >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] mod_wsgi >>>>>>>>>>> (pid=27565): Exception occurred processing WSGI script >>>>>>>>>>> '/opt/wgt_proxy/wgtproxyProj/ >>>>>>>>>>> wgtproxy/apache/django.wsgi'. >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> Traceback (most recent call last): >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] File >>>>>>>>>>> "/opt/wgt_proxy/wgtproxyProj/wgtproxy/apache/django.wsgi", line 50, >>>>>>>>>>> in >>>>>>>>>>> __call__ >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> return self.__application(environ, _start_response) >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] File >>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/core/handlers/wsgi.py", >>>>>>>>>>> >>>>>>>>>>> line 248, in __call__ >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> signals.request_finished.send(sender=self.__class__) >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] File >>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/dispatch/dispatcher.py", >>>>>>>>>>> >>>>>>>>>>> line 162, in send >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> response = receiver(signal=self, sender=sender, **named) >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] File >>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/__init__.py", >>>>>>>>>>> >>>>>>>>>>> line 82, in close_connection >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> conn.close() >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] File >>>>>>>>>>> "/opt/webtier/python_64/lib/python2.6/site-packages/django/db/backends/__init__.py", >>>>>>>>>>> >>>>>>>>>>> line 70, in close >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> self.connection.close() >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> OperationalError: ORA-03114: not connected to ORACLE >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] >>>>>>>>>>> [Fri Feb 20 17:40:51 2015] [error] [client xx.xx.xx.xx] Request >>>>>>>>>>> Failed for : /wgtproxy/admin/, Resp Code : [500] >>>>>>>>>>> >>>>>>>>>>> Can anyone help me solve my issue? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "modwsgi" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to [email protected]. >>>>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>> Google Groups "modwsgi" group. >>>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>>> send an email to [email protected]. >>>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "modwsgi" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> To post to this group, send email to [email protected]. >>>>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "modwsgi" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> To post to this group, send email to [email protected]. >>>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "modwsgi" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> Visit this group at http://groups.google.com/group/modwsgi. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>>> >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "modwsgi" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/modwsgi. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "modwsgi" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/modwsgi. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> > -- > You received this message because you are subscribed to the Google Groups > "modwsgi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] <javascript:>. > To post to this group, send email to [email protected] <javascript:> > . > Visit this group at http://groups.google.com/group/modwsgi. > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
