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