Что происходит в uWSGI с subprocess.Popen?

Question

[Дмитрий]

Объясните мне, пожалуйста, что происходит в моем приложении, запущенном через uWSGI, когда я в нем пытаюсь сделать subprocess.Popen?
Есть одна тонкость - я использую gevent и в uWSGI у меня используется встроенная возможность работы с gevent.

from gevent.subprocess import Popen, PIPE
import sys

def my_view(request, *args, **kwargs):
        sub = Popen(sys.executable + ' my_worker.py args', stdout=PIPE, shell=True)
        out, err = sub.communicate()
        return out

Когда запускаю локально через встроенный тестовый Django-сервер - все работает.
Когда запускаю через uWSGI, то при вызове вьюхи в логах uWSGI выдается ошибка:

unable to load configuration from my_worker.py

Что такое пытается сделать uWSGI? Какую еще конфигурацию он пытается искать в моем рабочем процессе, который нужно просто выполнить в субпроцессе?

Comments

[sim3x]

А что вам нужно сделать?

[Дмитрий]

sim3x, мне нужно в моём gevent-приложении вызвать долгий вложенный процесс, получить из него результаты и вернуть их пользователю.
PS. Я помню Ваше отношение к gevent :)

[sim3x]

Дмитрий,

my_view - джанговская вьюха?

[Дмитрий]

Pavel Denisov, мне не хочется вешать отдельный процесс, который бы постоянно проверял наличие задания. Задания должны поступать довольно редко, и хочется запускать их только по мере поступления.

[Дмитрий]

sim3x, нет, не совсем вьюха. Просто используются Джанговские модели. Результаты просто через print выводятся в консоль. Консольное Django-приложение, короче :)

[Дмитрий]

Pavel Denisov, Вы мне уже как-то советовали spooler. Я хочу найти способ попроще, который бы просто изредка вызывал вложенный процесс. Изредка - это буквально 10-20 раз за день! Из-за этого не хочется демонов вешать.

[sim3x]

Дмитрий,
насколько я понимаю, в данном случае sys.executable != питон, а равно uwsgi
А uwsgi при запуске требует конфига первым параметром

[Дмитрий]

Pavel Denisov, так нет же! Надо именно сразу по тыку пользователя скрипт исполнить :)

[Дмитрий]

Pavel Denisov, если я правильно понимаю смысл gevent, то блокироваться будет пользователь, вызвавший процесс (мне так и нужно, чтобы он ждал), а другие пользователи должны в это время нормально обслуживаться.

[Дмитрий]

Да, действительно в sys.executable оказался путь до /usr/bin/uwsgi-core!

[Дмитрий]

Pavel Denisov, джанго у меня gevent-ом пропатчен, равно как и пул к PostgreSQL, так что там асинхронность работает нормально.

[sim3x]

Дмитрий,

а в настройках uwsgi gevent вообще включен?

[Дмитрий]

sim3x, да, все включено. В логах все нормально -"running gevent loop engine". Проблема была в sys.executable - там действительно путь к uwsgi-core вместо питона. Сейчас проверю, будут ли действительно обрабатываться другие соединения, пока процесс выполняется...

[Дмитрий]

Все! Заработало!
Жаль, что нельзя отметить комментарий как ответ. Пришлось просто лайкнуть.

Answer 1

[Дмитрий]

Проблема была в том, что при запуске приложения из uWSGI в sys.executable лежит путь не к интерпретатору Питона, а к бинарнику uwsgi-core.
Спасибо Pavel Denisov и sim3x за помощь!

Answer 2

[Джок Таннер]

Будучи потомственным телепатом, предположу, что вы в файле my_worker.py делаете импорты, которые приводят к запуску встроенного веб-сервера flask. Где-то не хватает идиоматического “if __name__ == '__main__':”.

Comments

[Дмитрий]

нет, там в комментариях к вопросу проблема решилась :)