No "python manage dbshell" connects successfully! Thant the problem everything else is working fine, the only thing failing is when a Django project is running and tries to connect to DB.
I have tried everything as a said in my first post in this thread "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: " How do you want me to send you the stack trace ??? Post it here ???? Alex On Wednesday, March 11, 2015 at 11:29:07 AM UTC+2, Graham Dumpleton wrote: > > If you can get a stack trace out of the core file, sure I may be able to > see something. Depends on how much symbols are being stripped out of Apache > and other labels as to how useful it is. > > As far as database access, what happens if you su to the same user your > code runs as under Apache and run 'python manage dbshell' to get a shell > into Oracle. Does that fail as well. > > https://docs.djangoproject.com/en/1.7/ref/django-admin/#dbshell > > Graham > > On 11/03/2015, at 8:23 PM, [email protected] <javascript:> wrote: > > 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] 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]. >> 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.
