Nothing specific stands out. Couple of things to suggest.
Use 'httpd -M' to work out what modules Apache is loading. Run ldd on Apache binary and any modules it is loading to arrive that the set of shared libraries and versions they are linking. Run ldd on Oracle shared libraries to work out what shared libraries and versions they are linking. What might be happening is that if there are multiple versions of some shared libraries and they are incompatible, Apache or some module may be linking in an incompatible version to what Oracle itself is expecting. Maybe perhaps also run ldd in same way on lib pythonX.Y.so library for your Python version, mod_wsgi.so and any other Python extension modules in Python installation. BTW, you are loading mod_wsgi dynamically right and not trying to run it statically linked into Apache. Right now mod_wsgi will crash when run if linked statically to Apache. Graham On 11/03/2015, at 9:01 PM, [email protected] wrote: > stack trace : http://pastebin.com/kGEbvn2V > > track : http://pastebin.com/8ePDYj93 > > both links are for the same PID > > On Wednesday, March 11, 2015 at 11:41:31 AM UTC+2, Graham Dumpleton wrote: > I gist or paste bin may be better. > > Graham > > On 11/03/2015, at 8:40 PM, [email protected] wrote: > >> 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] 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, >>>>>>>>> [email protected] 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, >>>>>>>>>> [email protected] 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]. >>> 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.
