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.
