Hi Graham, I thought that too, that maybe there were some incompatible libraries so last week i upgraded the oracle client to 11.2.X and the cx_Oracle module in python and the problem was solved.
The very strange thing is that the environment was unstable at the beginning and by doing some test and debugging i noticed that all successful request had $ORACLE_HOME pointing to the Oracle HTTP Server installation and not in Oracle DB client. So i went and change every place i was setting the variable and now the system is stable and i have not had an error since then! Regards, Alex On Monday, March 16, 2015 at 10:07:00 AM UTC+2, Graham Dumpleton wrote: > > 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] <javascript:> 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, 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]. >>> 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.
