You're welcome, to be honest with you both Solaris and Oracle's HTTP Server (OHS) was a challenge with the module. During this period with all the research i did in order to troubleshoot the various problems i had, i never found someone having your module + Django setup in OHS... and somehow i am feeling that i broke new ground one this... and if you add Solaris to the equation i think that the degree of difficulty grow exponentially.
Alex On Tuesday, March 17, 2015 at 1:00:16 AM UTC+2, Graham Dumpleton wrote: > > 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] <javascript:> 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 > <http://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 ht <http://groups.google.com/group/modwsgi> > > ... -- 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.
