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.
