That is great to hear.

I don't really know of many who use Solaris so is good to know that mod_wsgi is 
still working there.

Thanks for letting me know.

Graham

On 16/03/2015, at 11:12 PM, [email protected] wrote:

> 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] 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.

-- 
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.

Reply via email to