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 ?? 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] <javascript:> 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] <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.
