So mod_python is not installed on the server and I have already the following
two apache config files...
/etc/apace2/mods-available/mod-wsgi.load:
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
/etc/apace2/mods-available/mod-wsgi.conf:
<IfModule mod_wsgi.c>
WSGIPythonHome /home/apache_user/workspace/python/current
</IfModule>
Looks correct?
On 16 May 2013, at 00:28, Graham Dumpleton <[email protected]> wrote:
> Try adding to the Apache configuration:
>
> WSGIPythonHome /home/apache_user/workspace/python/current
>
> It is possible that at runtime, because your Python is in a non standard
> location, that it is picking of the .py files from the standard location
> rather than where your Python installation is. This will force it to look in
> the correct location.
>
> Note that you MUST not be using mod_python in the same Apache as that will
> override this and cause it not to work.
>
> Graham
>
> On 15/05/2013, at 11:25 PM, ultra909 <[email protected]> wrote:
>
>> Hi Graham,
>>
>> So like Isaac, I am trying to get mod_wsgi to play with the Enthought Python
>> distro on Ubuntu.
>>
>> I have likewise followed the instructions for building with Multiple Python
>> Versions and run the following:
>>
>> make distclean
>> ./configure
>> --with-python=/home/apache_user/workspace/python/current/bin/python
>> LD_RUN_PATH=/home/apache_user/workspace/python/current/lib make
>> sudo make install
>>
>> When I try and start Apache, I just get the following in a loop in the
>> error.log:
>>
>> Traceback (most recent call last):
>> File "/usr/lib/python2.7/site.py", line 562, in <module>
>> main()
>> File "/usr/lib/python2.7/site.py", line 544, in main
>> known_paths = addusersitepackages(known_paths)
>> File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages
>> user_site = getusersitepackages()
>> File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages
>> user_base = getuserbase() # this will also set USER_BASE
>> File "/usr/lib/python2.7/site.py", line 236, in getuserbase
>> USER_BASE = get_config_var('userbase')
>> File "/usr/lib/python2.7/sysconfig.py", line 577, in get_config_var
>> return get_config_vars().get(name)
>> File "/usr/lib/python2.7/sysconfig.py", line 476, in get_config_vars
>> _init_posix(_CONFIG_VARS)
>> File "/usr/lib/python2.7/sysconfig.py", line 337, in _init_posix
>> makefile = _get_makefile_filename()
>> File "/usr/lib/python2.7/sysconfig.py", line 331, in _get_makefile_filename
>> return
>> os.path.join(get_path('platstdlib').replace("/usr/local","/usr",1), "config"
>> + (sys.pydebug and "_d" or ""), "Makefile")
>> AttributeError: 'module' object has no attribute 'pydebug'
>>
>> On Monday, 29 April 2013 01:18:55 UTC+2, Graham Dumpleton wrote:
>> Since I can't see in the prior discussion mention of the error given by the
>> traceback, can you go back to square one and explain your specific problem
>> from the start rather than just assuming it is related to the prior one. Not
>> knowing the background of what you are doing makes it hard to comment.
>>
>> Graham
>>
>> On 25/04/2013, at 5:28 AM, ultra909 <[email protected]> wrote:
>>
>>> Hi,
>>>
>>> I have EXACTLY the same problem as you. Have done all that and yet still
>>> get nothing out of Apache other than:
>>>
>>> [Wed Apr 24 15:15:55 2013] [info] mod_wsgi (pid=10234): Python home
>>> /home/strongshell/workspace/python/epd-7.3-1/.
>>> [Wed Apr 24 15:15:55 2013] [info] mod_wsgi (pid=10234): Initializing Python.
>>> Traceback (most recent call last):
>>> File "/usr/lib/python2.7/site.py", line 562, in <module>
>>> main()
>>> File "/usr/lib/python2.7/site.py", line 544, in main
>>> known_paths = addusersitepackages(known_paths)
>>> File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages
>>> user_site = getusersitepackages()
>>> File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages
>>> user_base = getuserbase() # this will also set USER_BASE
>>> File "/usr/lib/python2.7/site.py", line 236, in getuserbase
>>> USER_BASE = get_config_var('userbase')
>>> File "/usr/lib/python2.7/sysconfig.py", line 577, in get_config_var
>>> return get_config_vars().get(name)
>>> File "/usr/lib/python2.7/sysconfig.py", line 476, in get_config_vars
>>> _init_posix(_CONFIG_VARS)
>>> File "/usr/lib/python2.7/sysconfig.py", line 337, in _init_posix
>>> makefile = _get_makefile_filename()
>>> File "/usr/lib/python2.7/sysconfig.py", line 331, in
>>> _get_makefile_filename
>>> return
>>> os.path.join(get_path('platstdlib').replace("/usr/local","/usr",1),
>>> "config" + (sys.pydebug and "_d" or ""), "Makefile")
>>> AttributeError: 'module' object has no attribute 'pydebug'
>>>
>>>
>>> Clearly it's still hitting the base system python somehow - can't even get
>>> it to run a simple wsgi to dump out sys variables. My WSGIPythonHome is set
>>> to the directory above lib and bin... ldd looks all good... any ideas?
>>>
>>> TIA
>>>
>>> On Thursday, 10 January 2013 20:45:26 UTC+1, Isaac Shivvers wrote:
>>> Hi all,
>>>
>>> Just a quick bump, bringing this post back to life.
>>>
>>> I'm running a similar setup, and had a very similar problem:
>>> - attempting to run a mod_wsgi application using a specific, custom
>>> Enthought python build
>>> - used multiple-python guide here, and it appeared successful
>>> - but, I still had problems:
>>> - libraries that should work (numpy) did not
>>> - sys.version (inside wsgi application) reported default system version,
>>> not the one I wanted
>>>
>>> But, modifying the LD_RUN_PATH with make worked like a charm!
>>> I re-compiled mod_wsgi, as Graham suggested:
>>>
>>> make distclean
>>> ./configure --with-python=/path/to/python/executable
>>> LD_RUN_PATH=/path/to/python/lib make
>>> sudo make install
>>>
>>> Thanks for all the work you've put into mod_wsgi!
>>> -Isaac
>>>
>>>
>>>
>>>
>>> On Tuesday, May 3, 2011 4:46:30 PM UTC-7, Graham Dumpleton wrote:
>>> On 4 May 2011 03:41, Daniel O'Donovan <[email protected]> wrote:
>>> > Thanks for your help Graham, embarrassingly, many of my problems stemmed
>>> > from using
>>> >
>>> > $ service httpd restart
>>> >
>>> > to control my apache daemon rather than
>>> >
>>> > $ /etc/init.d/httpd restart
>>> >
>>> > As 'service' will remove some of your environment variables (PYTHONHOME
>>> > seems to be key - WSGIPythonHome didn't seem to have any effect).
>>> You should never rely on environment variables set in user environment
>>> being inherited because when box reboots it will fail.
>>>
>>> As I said before, WSGIPythonHome doesn't help with which shared
>>> library is found, only the runtime Python installation prefix. Your
>>> comments before suggested sys.path was correct which indicated that
>>> WSGIPythonHome was at least doing it job correctly. As per the
>>> documented I directed you to, the important value is sys.prefix and
>>> what that is set to within mod_wsgi.
>>>
>>> WSGIPythonHome should work so long as mod_python not loaded, you get
>>> the prefix you give it correct, Apache can read the directories for
>>> the installation and you haven't managed to inherit user environment
>>> variables that screw it all up.
>>>
>>> >> What do you mean here? Ie., what does patchelf do and how does it
>>> >> change the output from ldd on mod_wsgi.so?
>>> >
>>> > patchelf modifies the dynamic linker and RPATH of ELF executables.
>>> > Unfortunately setting --with-python= and LD_RUN_PATH had no effect for
>>> > me, so but a quick
>>> >
>>> > $ patchelf --set-rpath /lib64:/path/to/my/custom/lib
>>> > /etc/httpd/modules/mod_wsgi.so
>>> >
>>> > did the job. - ldd now searches for dynamic libs in /lib64 and
>>> > /path/to/my/custom/lib and finds the appropriate non-system python.
>>>
>>> Setting LD_RUN_PATH in user environment when building mod_wsgi should
>>> work. I can't say what you have done wrong as you haven't supplied
>>> exact logs of what commands you ended up running to build it and what
>>> subsequent ldd output was. Also don't know what other user environment
>>> variables you had set which could cause problems.
>>>
>>> Anyway, if you have got it working then doesn't matter I guess.
>>>
>>> Graham
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> 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?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>
>>
>> --
>> 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?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> You received this message because you are subscribed to a topic in the Google
> Groups "modwsgi" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/modwsgi/DW0DzFrF1YY/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, 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?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
