mod_wsgi не находит модули - apache, RHEL, python3.4

У меня mod_wsgi нормально работал на RHEL / Apache2.4 / python3.4 / Django1.11 / virtualenv. Затем я использовал pip в virtualenv для обновления numpy с 1.14.0 до 1.14.2, установки pandas и установки пары других модулей. Затем я перезапустил Apache и начал получать ошибки сервера, указывающие AttributeError: 'module' object has no attribute 'arange' when trying to call numpy.arange, или аналогичные ошибки при попытке вызвать matplotlib.use ('Agg') и т. Д.

Я заменил wsgi.py следующим, и он отлично работает. Как только я раскомментирую любой из вызовов numpy или matplotlib, он возвращает ошибку 500, а в журнале ошибок apache отображается ошибка, похожая на AttributeError: 'module' object has no attribute ...

import datetime
import sys
import numpy as np
import matplotlib as mpl
import mod_wsgi

def application(env, start_response):

    #mpl.use('Agg')
    #a = np.arange(15).reshape(3, 5)
    #a = np.array([2,3,4])

    status = '200 OK'
    output = 'Hello World! This is the wsgi app generated from python!'
    output += '\n\ncurrent time is: '+str(datetime.datetime.now())
    output += '\n\nsys.executable='+sys.executable
    output += '\n\nsys.path='+str(sys.path)
    output += '\n\nsys.version=' + str(sys.version)
    output += '\n\nsys.prefix=' +  str(sys.prefix)
    output += '\n\nmod_wsgi.version='+str(mod_wsgi.version)
    output += '\n\n\nEnvironment Variables:\n\n'+'\n'.join('%s: %s' % (k, v) for (k, v) in env.items())
    output = bytes(output,'utf-8')
    response_headers = [('Content-type', 'text/plain'),
                            ('Content-Length', str(len(output)))]
    start_response(status, response_headers)
    return [output]

Соответствующий вывод этого wsgi.py:

sys.executable=/usr/bin/python3
sys.path=['/usr/local/virtualenvs/myapp/wsgiapp', '/usr/local/virtualenvs/myapp/lib64/python34.zip', '/usr/local/virtualenvs/myapp/lib64/python3.4', '/usr/local/virtualenvs/myapp/lib64/python3.4/plat-linux', '/usr/local/virtualenvs/myapp/lib64/python3.4/lib-dynload', '/usr/lib64/python3.4', '/usr/lib/python3.4', '/usr/local/virtualenvs/myapp/lib/python3.4/site-packages']
sys.version=3.4.8 (default, Mar 23 2018, 10:04:27) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)]
sys.prefix=/usr/local/virtualenvs/myapp
mod_wsgi.version=(4, 5, 24)
mod_wsgi.process_group: mywsgiapp
mod_wsgi.application_group: 

Apache httpd.conf не изменился. Соответствующие строки:

LoadModule wsgi_module "/usr/local/virtualenvs/myapp/lib64/python3.4/site-packages/mod_wsgi/server/mod_wsgi-py34.cpython-34m.so"
WSGIDaemonProcess mywsgiapp python-home=/usr/local/virtualenvs/myapp python-path=/usr/local/virtualenvs/myapp/wsgiapp
WSGIProcessGroup mywsgiapp
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias /myapp /usr/local/virtualenvs/myapp/wsgiapp/wsgi.py process-group=mywsgiapp application-group=%{GLOBAL}

Я не уверен, что послужило причиной поломки. Я знаю, что это обычно происходит, когда mod_wsgi скомпилирован для неправильной версии python. Но раньше это работало нормально, и все по-прежнему выглядит правильно настроенным: mod_wsgi работает, вывод wsgi.py указывает, что он использует правильную версию python, а каталог site-packages для virtualenv находится в python- дорожка.

У меня установлен mod_wsgi в основном месте python3.4, и я попытался указать Apache LoadModule в этом экземпляре, но все равно получаю те же ошибки.

Что еще я должен проверить?

Должен ли sys.executable указывать на virtualenv вместо основной установки python? Стоит ли мне pip uninstall все модули и начинать заново?

Кроме того, чтобы установить pandas, мне пришлось установить Cython, который, в свою очередь, потребовал установки gcc-c ++ (sudo yum install gcc-c++). Это повлияет на что-нибудь?

Отредактировано, чтобы добавить следы ошибок. Я раскомментировал строку a = np.arange(15).reshape(3, 5) в приведенном выше файле wsgi.py.

Страница ошибки HTTP от Apache:

Внутренняя Ошибка Сервера

Сервер обнаружил внутреннюю ошибку или неправильную конфигурацию и не смог выполнить ваш запрос.

Свяжитесь с администратором сервера по адресу root @ localhost, чтобы сообщить им время возникновения этой ошибки и действия, которые вы выполнили непосредственно перед этой ошибкой.

Дополнительная информация об этой ошибке может быть доступна в журнале ошибок сервера.

Журнал ошибок Apache (обратите внимание, что я вычеркнул IP-адрес перед публикацией здесь):

[Thu Jul 12 23:01:15.664941 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] mod_wsgi (pid=21490): Exception occurred processing WSGI script '/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py'.
[Thu Jul 12 23:01:15.727450 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] Traceback (most recent call last):
[Thu Jul 12 23:01:15.727814 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961]   File "/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py", line 14, in application
[Thu Jul 12 23:01:15.727831 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961]     a = np.arange(15).reshape(3, 5)
[Thu Jul 12 23:01:15.727865 2018] [wsgi:error] [pid 21490] [remote 10.x.x.x:59961] AttributeError: 'module' object has no attribute 'arange'

Ошибка при попытке показать np. файл:

[Thu Jul 12 23:25:59.196534 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] mod_wsgi (pid=22747): Exception occurred processing WSGI script '/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py'.
[Thu Jul 12 23:25:59.257214 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] Traceback (most recent call last):
[Thu Jul 12 23:25:59.257500 2018] [wsgi:error] [pid 22747] [remote 10.x.x:60353]   File "/usr/local/virtualenvs/myapp/wsgiapp/wsgi.py", line 23, in application
[Thu Jul 12 23:25:59.257535 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353]     output += '\\n\\nnumpy file location='+str(np.__file__)
[Thu Jul 12 23:25:59.257569 2018] [wsgi:error] [pid 22747] [remote 10.x.x.x:60353] AttributeError: 'module' object has no attribute '__file__'

Кроме того, для справки, импорт модулей работает нормально, если я активирую virtualenv и использую интерпретатор:

Python 3.4.8 (default, Mar 23 2018, 10:04:27)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-16)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.__file__
'/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy/__init__.py'

Печать dir (np) из файла wsgi.py приводит к:

dir(np)=['__doc__', '__loader__', '__name__', '__package__', '__path__', '__spec__']

Так что это не ошибка, но это не полный список идентификаторов. Запуск dir (np) из интерпретатора virtualenv приводит к:

['ALLOW_THREADS', 'AxisError', 'BUFSIZE', 'CLIP', 'ComplexWarning', 'DataSource', 'ERR_CALL', ..... clipped for brevity - there's a full screen of items in the list

Поскольку в нем перечислены некоторые идентификаторы, вот результаты печати каждого из них из wsgi.py. Похоже, пакет забирается с правильного пути.

np.__path__ =_NamespacePath(['/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy'])
np.doc=None
np.loader=<_frozen_importlib._NamespaceLoader object at 0x7f83b82e0c88>
np.package=numpy
np.name=numpy
np.Spec=ModuleSpec(name='numpy', loader=None, origin='namespace', submodule_search_locations=_NamespacePath(['/usr/local/virtualenvs/myapp/lib/python3.4/site-packages/numpy']))

Чтобы убедиться, что wsgi / python действительно находит пакет numpy, я изменил файл wsgi.py, чтобы импортировать несуществующий пакет import foo as np, и когда я снова запустил его, он выдал ошибку ImportError: No module named 'foo'. Так что, похоже, он действительно находит пакеты сайтов ... но просто не загружает их полностью?


person jd80    schedule 13.07.2018    source источник
comment
Включите полную трассировку и описание исключения Python.   -  person Graham Dumpleton    schedule 13.07.2018
comment
Ошибка HTTP и добавлены журналы   -  person jd80    schedule 13.07.2018
comment
Добавьте код в файл сценария WSGI для вывода np.__file__. Определите, откуда импортируется numpy.   -  person Graham Dumpleton    schedule 13.07.2018
comment
добавлена ​​ошибка при попытке распечатать расположение файла модуля   -  person jd80    schedule 13.07.2018
comment
Что вы получите за dir(np), если выкинете это?   -  person Graham Dumpleton    schedule 13.07.2018
comment
обновлено с результатами dir (np) - это не ошибка, но, похоже, не получает все идентификаторы numpy   -  person jd80    schedule 13.07.2018
comment
Вы пробовали pip uninstall numpy? Запустите его несколько раз, пока не скажет, что он не установлен. Затем снова запустите pip install для получения правильной версии numpy.   -  person Graham Dumpleton    schedule 13.07.2018
comment
да, я попытался удалить numpy, убедился, что его больше нет в пакетах сайтов в virtualenv, а затем переустановил его. И, поскольку я обновился с 1.14.0 до 1.14.2, я также безуспешно пытался удалить, а затем переустановить версию 1.14.0. Вот почему я не понимаю, стоит ли мне удалить все модули (и пакет gcc-c ++ yum) и начать заново.   -  person jd80    schedule 13.07.2018
comment
Есть ли шанс, что у вас есть несколько LoadModule строк для wsgi_module, и он ранее загружал системный пакет для mod_wsgi?   -  person Graham Dumpleton    schedule 13.07.2018
comment
Только один LoadModule используется во всем файле httpd.conf.   -  person jd80    schedule 13.07.2018
comment
Единственное, о чем можно думать, это о том, что SELinux включен и что-то не так. В частности, может вызвать проблемы с загрузкой модулей расширения.   -  person Graham Dumpleton    schedule 13.07.2018
comment
Я не нашел окончательных ответов на них в документации (или если они имеют значение): следует ли скомпилировать mod_wsgi и ссылаться на него в основной установке python или в virtualenv? Должен ли sys.executable указывать на virtualenv вместо основной установки python?   -  person jd80    schedule 13.07.2018
comment
Грэм - большое спасибо за помощь! Я многому научился в этом процессе и очень ценю ваши усилия по поддержке mod-wsgi!   -  person jd80    schedule 13.07.2018


Ответы (1)


Интересный факт: когда pip устанавливает новый модуль, он устанавливает разрешения таким образом, чтобы пользователь мог импортировать и использовать модули, как ожидалось, но «другие» разрешения позволяют модулям видеть, но не выполнять. Таким образом, mod_wsgi, работающий под Apache, мог импортировать модули, но вызов любых методов приводил к ошибке.

Решение: дважды проверьте разрешения после установки или обновления модулей Python! Я установил все каталоги на 755 и все файлы на 644, и это, похоже, сработало. Или, как упоминалось в комментарии, убедитесь, что ваша umask установлена ​​правильно перед запуском pip.

person jd80    schedule 13.07.2018
comment
Ваше описание звучит неправильно. Это не имеет ничего общего с pip, это регулируется тем, что umask для вашей учетной записи было установлено на время запуска pip. Типичный umask равен 0022. Это приведет к тому, что файлы будут по-прежнему доступны для чтения, а каталоги будут доступны для чтения и выполнения (с возможностью поиска). Это должно быть хорошо. Проблема может возникнуть только в том случае, если вы изменили свой umask на что-то более ограничивающее, так что исполняемый бит остался в каталогах для других. - person Graham Dumpleton; 14.07.2018