On 13/06/2014, at 9:07 AM, Helio Gutierrez <[email protected]> wrote:
> Ok..
>
> I searched the file "/usr/lib64/libpython2.7.so.1.0" and i found that is a
> link to "/usr/local/lib/libpython2.7.so.1.0", but i don't know how it happen
> that in the installation.
Even if the Python shared library is linked into /usr/lib64, it is still
advisable to ensure you are setting WSGIPythonHome to /usr/local.
This is because the way an embedded Python interpreter finds the appropriate
.../lib/pythonX.Y, is by looking for the 'python' executable in PATH.
If there is one in /usr/bin, it will find that and set up sys.prefix as /usr
and use the lib directory under /usr/lib/pythonX.Y.
The WSGIPythonHome must be outside of any VirtualHost.
If you are even getting as far as you are, I am worried about what it may be
find in /usr/lib then.
Do either of these exist and what do they refer to:
/usr/lib/python2.7
/usr/lib64/python2.7
As far as removing a Python installation, it will have installed things under:
/usr/local/bin/{various executables}
/usr/local/lib/python2.7
/usr/local/include/python2.7
For a patch level update only, it generally should have been safe to simple
install over the top of the existing versions.
Anyway, as per:
http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use
I would be double checking where Python is getting stuff from with a hello
world.
Add to then printing out of sys.path and provide the results.
As to the original error, one final possibility may be that it is failing
because you have SELinux extensions enabled.
Try disabling them temporarily and try again.
http://www.crypt.gen.nz/selinux/disable_selinux.html
If reinstalling Python, make sure you are using '--enable-shared' to configure
for Python. Ensure you did a 'make distclean' in Pythin before running
configure again to rebuild it.
Graham
> This is my history:
>
> First i had python2.7.6 (compiled from sources) and i only remove
> /usr/local/lib/python2.7 folder and installed the new version 2.7.7 in the
> same location (compiled from sources too).
>
> There are some way to remove a Python instalation compiled from sources?
>
> I will try uninstall python and mod_wsgi and install it again.
>
>
>
>
> El martes, 10 de junio de 2014 20:27:04 UTC-5, Graham Dumpleton escribió:
>
> On 11/06/2014, at 1:53 AM, Helio Gutierrez <[email protected]> wrote:
>
>> Thank you Graham!
>>
>> Its correct, my problem was that i had loaded mod_python and i have already
>> commented this function in /etc/httpd/conf.d/python.conf:
>>
>> #LoadModule python_module modules/mod_python.so
>>
>> I did your next recomendations:
>>
>> - reinstall mod_wsgi with your instructions
>> - block mod_python
>> - remove in the pythonpath the text ":/usr/local/lib/python2.7/site-packages"
>> - WSGIPythonHome /usr/local: did'nt work because my vhost.conf is into
>> virtual host and i have only one version 2.7.7 (compiled from sources) under
>> /usr/local/lib.
>
> The reason for suggesting that was that you showed:
>
> [root@u16844278 mod_wsgi-3.5]# ldd /usr/lib64/httpd/modules/mod_wsgi.so
> linux-vdso.so.1 => (0x00007fff15fff000)
> libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
> (0x00007fd1eb3ee000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd1eb1d1000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007fd1eafcc000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00007fd1eadc9000)
> libm.so.6 => /lib64/libm.so.6 (0x00007fd1eab45000)
> libc.so.6 => /lib64/libc.so.6 (0x00007fd1ea7b0000)
> /lib64/ld-linux-x86-64.so.2 (0x00007fd1eba07000)
>
> This indicates that libpython2.7.so was being picked up from /usr/lib64.
>
> If you had installed Python 2.7.7 under /usr/local, then the shared library
> would not normally have been installed in /usr/lib64 but /usr/local/lib.
>
> Thus having it find that that other library suggests that you have a separate
> Python 2.7 installation, not necessarily the same patch revision.
>
> If there is a separate Python 2.7 installation, it is quite important the
> both the correct shared library is found at runtime, as well as the correct
> Pythin installation itself.
>
> For the library, the LD_RUN_PATH fix was needed and to find the right Python
> installation WSGIPythonHome is necessary.
>
> If you do have a separate Python 2.7 installation installed system wide, even
> if the correct libpython2.7.so is found in /usr/local/lib, the way the
> embedded Python finds the Python installation means that it would still use
> the system wide one, which could cause issues.
>
> Either way, just make sure you can check. You can do:
>
> http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Installation_In_Use
>
> The value of sys.prefix should match that for the Python installation you
> want it to use.
>
>> Now my error was gone, but i have another different error: (this is for a
>> bad path?)
>>
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] mod_wsgi
>> (pid=31984): Exception occurred processing WSGI script
>> '/var/www/html/holding/src/wsgi.py'.
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] Traceback (most
>> recent call last):
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line
>> 187, in __call__
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94]
>> self.load_middleware()
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/core/handlers/base.py", line
>> 47, in load_middleware
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] mw_instance =
>> mw_class()
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/middleware/locale.py", line
>> 24, in __init__
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] for
>> url_pattern in get_resolver(None).url_patterns:
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py", line
>> 365, in url_patterns
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] patterns =
>> getattr(self.urlconf_module, "urlpatterns", self.urlconf_module)
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/core/urlresolvers.py", line
>> 360, in urlconf_module
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94]
>> self._urlconf_module = import_module(self.urlconf_name)
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/utils/importlib.py", line 40,
>> in import_module
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94]
>> __import__(name)
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/var/www/html/holding/src/urls.py", line 18, in <module>
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] from
>> django.contrib import admin
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/contrib/admin/__init__.py",
>> line 6, in <module>
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] from
>> django.contrib.admin.sites import AdminSite, site
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] File
>> "/usr/local/lib/python2.7/site-packages/django/contrib/admin/sites.py", line
>> 3, in <module>
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] from
>> django.contrib.admin import ModelAdmin, actions
>> [Mon Jun 09 21:19:14 2014] [error] [client 189.219.102.94] ImportError:
>> cannot import name actions
>
> I am entirely sure that this point. It could be caused by a mixup with
> different Python installations. Only other cause could be not all
> directories/files being readable to user your code runs under as Apache, but
> that seems unlikely given it got as far as it did.
>
>> etc/profile
>>
>> unset i
>> unset -f pathmunge
>> export LD_LIBRARY_PATH=/opt/PostgreSQL/9.2/lib:/usr/local/lib
>
>
> To avoid the need for that system wide LD_LIBRARY_PATH, when installing
> psycopg2, if that is what you are using, you should use LD_RUN_PATH again.
>
> LD_RUN_PATH=/opt/PostgreSQL/9.2/lib pip install psycopg2
>
> I have never seen people having psycopg2 use the wrong libpq though, which
> leads me to think that the setup.py for psycopg2 handles that mixup
> automatically somehow.
>
> Graham
>
>> El lunes, 9 de junio de 2014 15:52:05 UTC-5, Graham Dumpleton escribió:
>> First up, stop loading mod_python into Apache. It is using a different
>> Python version and is likely the cause of all the problems as you cannot use
>> both mod_python and mod_wsgi together when they are using different Python
>> versions.
>>
>> Second, if you mean you installed Python 2.7.7 from source code and at the
>> same time you still had a system Python 2.7 of a different patch level
>> revision, then mod_wsgi.so is linked against the shared library from the
>> wrong Python installation>
>>
>> Your mod_wsgi.so should be loading libpython2.7.so from /usr/local/lib.
>>
>> You should go back into mod_wsgi source code and do:
>>
>> make distclean
>> ./configure --with-python=/usr/local/bin/python
>> LD_RUN_PATH=/usr/local/lib make
>> sudo make install
>>
>> Check again whether ldd is picking up the wrong library.
>>
>> There also should be no need to list /usr/local/lib/python2.7/site-packages
>> in python-path.
>>
>> When using an alternate Python installation under /usr/local and a global
>> one is being picked up instead, use:
>>
>> WSGIPythonHome /usr/local
>>
>> Albeit that this will not work if mod_python is also loaded even if using
>> the same Python version. Another reason why you shouldn't use mod_python at
>> same time.
>>
>> Also, if you are using a Python virtual environment as well, which is
>> correctly built from the Python 2.7.7 under /usr/local, then you can drop
>> the sys.path fixes up in your WSGI script file for having it be used and
>> instead simply use:
>>
>> WSGIDaemonProcess holding python-home=/var/www/html/holding
>>
>> where python-home is set to the value of sys.prefix for that Python virtual
>> environment.
>>
>> Graham
>>
>>
>> On 10/06/2014, at 5:06 AM, Helio Gutierrez <[email protected]> wrote:
>>
>>> Hi
>>>
>>> I've downloaded Python 2.7.7 and compiled mod_wsgi3.5 with that Python
>>> version on Centos 6.5 (Parallel Desktop 11) with Django 1.6.2, but i have
>>> an error in my server.
>>>
>>> I have the next configuration, maybe someone can help me:
>>>
>>>
>>> Apache/2.2.15 (Unix) DAV/2 mod_fcgid/2.3.6 mod_python/3.3.1 Python/2.6.6
>>> mod_ssl/2.2.15 OpenSSL/1.0.1e-fips mod_wsgi/3.5 Python/2.7.7 mod_perl/2.0.4
>>> Perl/v5.10.1 configured -- resuming normal operations
>>>
>>> [root@u16844278 mod_wsgi-3.5]# ldd /usr/lib64/httpd/modules/mod_wsgi.so
>>> linux-vdso.so.1 => (0x00007fff15fff000)
>>> libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0
>>> (0x00007fd1eb3ee000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd1eb1d1000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00007fd1eafcc000)
>>> libutil.so.1 => /lib64/libutil.so.1 (0x00007fd1eadc9000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00007fd1eab45000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00007fd1ea7b0000)
>>> /lib64/ld-linux-x86-64.so.2 (0x00007fd1eba07000)
>>>
>>>
>>> vhost.conf:
>>>
>>> WSGIDaemonProcess holding
>>> python-path=/var/www/html/holding/src:/usr/local/lib/python2.7/site-packages
>>> WSGIProcessGroup holding
>>>
>>> WSGIScriptAlias / /var/www/html/holding/src/wsgi.py
>>>
>>> <Location "/">
>>> Order Allow,Deny
>>> Allow from all
>>> </Location>
>>>
>>> Alias /static/admin/
>>> /usr/local/lib/python2.7/site-packages/django/contrib/admin/static/admin
>>>
>>> <Location "/static">
>>> SetHandler None
>>> </Location>
>>>
>>> Alias /static/ /var/www/vhosts/mysite.com/holding/static
>>>
>>> <Location "/media">
>>> SetHandler None
>>> </Location>
>>>
>>> Alias /media /var/www/vhosts/mysite.com/holding/media
>>>
>>> <LocationMatch "\.(jpg|gif|png|css|js)$">
>>> SetHandler None
>>> </LocationMatch>
>>>
>>>
>>>
>>> wsgi.py
>>>
>>> import os, sys
>>>
>>> sys.path.append('/usr/local/lib/python2.7')
>>> sys.path.append('/usr/local/lib/python2.7/site-packages')
>>>
>>> sys.path.append('/var/www/html/holding')
>>> sys.path.append('/var/www/html/holding/src')
>>>
>>> prev_sys_path = list(sys.path)
>>>
>>> # reorder sys.path so new directories from the addsitedir show up first
>>> new_sys_path = [p for p in sys.path if p not in prev_sys_path]
>>> for item in new_sys_path:
>>> sys.path.remove(item)
>>> sys.path[:0] = new_sys_path
>>>
>>>
>>> os.environ['DJANGO_SETTINGS_MODULE'] = 'src.settings'
>>>
>>> from django.core.wsgi import get_wsgi_application
>>> application = get_wsgi_application()
>>>
>>>
>>> error_log
>>>
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] mod_wsgi
>>> (pid=12642): Target WSGI script '/var/www/html/holding/src/wsgi.py' cannot
>>> be loaded as Python module.
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] mod_wsgi
>>> (pid=12642): Exception occurred processing WSGI script
>>> '/var/www/html/holding/src/wsgi.py'.
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] Traceback (most
>>> recent call last):
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] File
>>> "/var/www/html/holding/src/wsgi.py", line 38, in <module>
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] from
>>> django.core.wsgi import get_wsgi_application
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] File
>>> "/usr/local/lib/python2.7/site-packages/django/core/wsgi.py", line 1, in
>>> <module>
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] from
>>> django.core.handlers.wsgi import WSGIHandler
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] File
>>> "/usr/local/lib/python2.7/site-packages/django/core/handlers/wsgi.py", line
>>> 4, in <module>
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] import
>>> logging
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] File
>>> "/usr/local/lib/python2.7/logging/__init__.py", line 26, in <module>
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] import sys,
>>> os, time, cStringIO, traceback, warnings, weakref, collections
>>> [Mon Jun 09 12:49:45 2014] [error] [client 189.219.102.94] SystemError:
>>> dynamic module not initialized properly
>>>
>>> --
>>> 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.
