Nginx uwsgi internal server error

Internal Server Error with Django and uWSGI 2 Emperor mode (ONLY) #650

When I run uswsgi services WITHOUT running it in emperor mode my django website runs just fine. No matter how I change my configuration I always get the error message my /tmp/uwsgi.log file: «— no python application found, check your startup logs for errors —» I have listed my configuration and error log below:

OS version: Linux raspberrypi 3.6.11+ #538 armv6l GNU/Linux
Django version: 1.6.5
uwsgi version: 2.0.5.1

Virtual environment: /var/www/testbed/env
Project location: /var/www/testbed/project/auth
project tree:

Command being executed listed below:

Error file /tmp/uwsgi.log:

At this point, I’m grasping at straws. Out of all the reading that I have done I can’t see why this keeps rendering the «Internal Server Error.» I may have over looked something that why I’ve finally given in to my pride by posting my sorrows here. Since I’ve gotten this far I really do think that I have overlooked something very small. Any help would be greatly appreciated.

The text was updated successfully, but these errors were encountered:

sorry, but the config is completely wrong, i fear you do not have a clear situation about the Emperor, vassals and standard instances. I will try to make a list, but i suggest you to start over from an official quickstart.

• Binding the Emperor to an http address requires that address to be configured to route requests to some vassal. There are dozens of ways to do it. Basically the errors you get are from the http router in the Emperor that do not know what to do with the request.
• mount and manage-script-name are for hosting multiple apps in the same process. It is not your case. For django, wsgi-file is more than enough
• You are telling the Emperor to monitor the /etc/uwsgi/vassals directory 2 times (one in the ini and another in the command line, this is not an error but wastes resources)
• with —binary-path in the Emperor you are changing the binary used by vassals (this could lead to some headache if you do not know what you are doing)
• loading the python plugin in the Emperor makes no sense (unless special case) as the Emperor does not run code generally
• vassals inherit the stdin,stdout and stderr of the Emperor, so if you plan to use the same log file for both, you should avoid reopening it in the vassal (it will be automatically used)

I have taken all your suggestions and cleaned the command that I was using along with editing the files to make appropriate corrections. The most important bullet, which was also the cause of most of my dismay, was what you mentioned about «binding the Emperor to an http address requires that address to be configured to route requests to some vassal.» It seems that I have misunderstood the instructions here. Listed below is the adjusted command that I execute after reading your response:

/var/www/testbed/env/bin/uwsgi —ini /etc/uwsgi/emperor.ini —http 127.0.0.1:8000

Which still doesn’t work. But the command that does work is below:

/var/www/testbed/env/bin/uwsgi —ini /etc/uwsgi/vassals/auth.ini —http 127.0.0.1:8000

What confuses me is that when I run the command directly using the ‘auth.ini’ file (listed above) everything works. The url (http://127.0.0.1:8000/testbed/auth/admin) is active and available. Though I have read many, many, parts of the the documentation over, and over, again I seem to be misinterpreting what I’m reading; leading me into an abyss-of-ignorance. This leads me to my next question. Is it possible to run uwsgi in ‘Emperor’ mode without configuring nginx? In my ignorant state I assume that what you mean by «binding the Emperor to an http address» is to use nginx (lighthttp, apache, cherokee, etc) as a proxy . Thanks for your insight thus-far.

yes you can bind an http router/proxy from the Emperor (without the need of nginx or other webservers), but you need to configure it to route requests to vassals using some rule. The Emperor is used to spawn multiple uWSGI instances, so its http router must know to which of them the request must be passed. Generally you use the domain name as the key (something like domain example.com goes to socket :4040). Here you find the options of the http router: http://uwsgi-docs.readthedocs.org/en/latest/Options.html#plugin-http. The most powerful way is the subscription system: http://uwsgi-docs.readthedocs.org/en/latest/SubscriptionServer.html

The docs refer to the fastrouter, but the options are the same just rename —fastrouter-subscription-server to http-subscription-server and your http router will start accepting subscriptions from vassals.

Finally, if you plan to host a single app, do not use the Emperor, it makes no sense.

Источник

Ошибка 500 internal server error Nginx

При разработке веб-сайтов и веб-приложений можно столкнуться с ошибкой 500 internal server error. Сначала она может испугать и ввести в заблуждение, поскольку обычно веб-сервер выдает более конкретные ошибки, в которых указана точная причина проблемы, например, превышено время ожидания, неверный запрос или файл не найден, а тут просто сказано что, обнаружена внутренняя ошибка.

Но не все так страшно и в большинстве случаев проблема вполне решаема и очень быстро. В этой статье мы разберем как исправить ошибку Internal server error в Nginx.

Как исправить 500 internal server error Nginx

Дословно Internal server error означает внутренняя ошибка сервера. И вызвать её могут несколько проблем. Вот основные из них:

• Ошибки в скрипте на PHP — одна из самых частых причин;
• Превышено время выполнения PHP скрипта или лимит памяти;
• Неправильные права на файлы сайта;
• Неверная конфигурация Nginx.

А теперь рассмотрим каждую из причин более подробно и разберем варианты решения.

1. Ошибка в скрипте PHP

Мы привыкли к тому, что если в PHP скрипте есть ошибки, то сразу же видим их в браузере. Однако на производственных серверах отображение сообщений об ошибках в PHP отключено, чтобы предотвратить распространение информации о конфигурации сервера для посторонних. Nginx не может отобразить реальную причину ошибки, потому что не знает что за ошибка произошла, а поэтому выдает универсальное сообщение 500 internal server error.

Чтобы исправить эту ошибку, нужно сначала понять где именно проблема. Вы можете включить отображение ошибок в конфигурационном файле php изменив значение строки display_errors с off на on. Рассмотрим на примере Ubuntu и PHP 7.2:

sudo systemctl restart php-fpm

Затем обновите страницу и вы увидите сообщение об ошибке, из-за которого возникла проблема. Далее его можно исправить и отключить отображение ошибок, тогда все будет работать. Ещё можно посмотреть сообщения об ошибках PHP в логе ошибок Nginx. Обычно он находится по пути /var/log/nginx/error.log, но для виртуальных доменов может настраиваться отдельно. Например, смотрим последние 100 строк в логе:

tail -n 100 -f /var/log/nginx/error.log

Теперь аналогично, исправьте ошибку и страница будет загружаться нормально, без ошибки 500.

2. Превышено время выполнения или лимит памяти

Это продолжение предыдущего пункта, так тоже относится к ошибкам PHP, но так, как проблема встречается довольно часто я решил вынести её в отдельный пункт. В файле php.ini установлены ограничения на время выполнения скрипта и количество оперативной памяти, которую он может потребить. Если скрипт потребляет больше, интерпретатор PHP его убивает и возвращает сообщение об ошибке.

Также подобная ошибка может возникать, если на сервере закончилась свободная оперативная память.

Если же отображение ошибок отключено, мы получаем error 500. Обратите внимание, что если время ожидания было ограничено в конфигурационном файле Nginx, то вы получите ошибку 504, а не HTTP ERROR 500, так что проблема именно в php.ini.

Чтобы решить проблему увеличьте значения параметров max_execution_time и memory_limit в php.ini:

sudo vi /etc/php/7.2/php.ini

max_execution_time 300
memory_limit 512M

Также проблема может быть вызвана превышением других лимитов установленных для скрипта php. Смотрите ошибки php, как описано в первом пункте. После внесения изменений в файл перезапустите php-fpm:

sudo systemctl restart php-fpm

3. Неверные права на файлы

Такая ошибка может возникать, если права на файлы, к которым обращается Nginx установлены на правильно. Сервисы Nginx и php-fpm должны быть запущены от имени одного и того же пользователя, а все файлы сайтов должны принадлежать этому же пользователю. Посмотреть от имени какого пользователя запущен Nginx можно командой:

nginx -T | grep user

Чтобы узнать от какого пользователя запущен php-fpm посмотрите содержимое конфигурационного файла используемого пула, например www.conf:

sudo vi /etc/php-fpm.d/www.conf

В моем случае это пользователь nginx. Теперь надо убедится, что файлы сайта, к которым вы пытаетесь обратиться принадлежат именно этому пользователю. Для этого используйте команду namei:

namei -l /var/www/site

Файлы сайта должны принадлежать пользователю, от имени которого запущены сервисы, а по пути к каталогу с файлами должен быть доступ на чтение для всех пользователей. Если файлы принадлежат не тому пользователю, то вы можете все очень просто исправить:

sudo chown nginx:nginx -R /var/www/site

Этой командой мы меняем владельца и группу всех файлов в папке на nginx:nginx. Добавить права на чтение для всех пользователей для каталога можно командой chmod. Например:

sudo chmod o+r /var/www/

Далее все должно работать. Также, проблемы с правами может вызывать SELinux. Настройте его правильно или отключите:

Выводы

В этой статье мы разобрали что делать если на вашем сайте встретилась ошибка 500 internal server error nginx. Как видите проблема вполне решаема и в большинстве случаев вам помогут действия описанные в статье. А если не помогут, напишите свое решение в комментариях!

Похожие записи

Нет похожих записей.

Оцените статью

Об авторе

Основатель и администратор сайта losst.ru, увлекаюсь открытым программным обеспечением и операционной системой Linux. В качестве основной ОС сейчас использую Ubuntu. Кроме Linux, интересуюсь всем, что связано с информационными технологиями и современной наукой.

2 комментария к “Ошибка 500 internal server error Nginx”

Чушь.
1. header(«http/1.1 500 Internal Server Error») ;
И логи не помогут.
2. Если скрипт превышает лимиты, то, вероятнее всего, в коде что-то не так. Бесконечный цикл, например. С ним, кстати, и увеличение этих лимитов не спасёт.

статья однобока. проблема к nginx вряд ли имеет отношение, зря в заголовок вынесено название этого великолепного сервера. nginx может работать, и работает, в связке не только с PHP. а на PHP свет клином не сошёлся. если уж пишете о PHP то и выносите в заголовок PHP, а не nginx.

инициировать такую ошибку можно элементарно. например, отключаем сервис PostgreSQL и вуаля. Welcome home, dear!

Источник

Частые ошибки в настройках Nginx, из-за которых веб-сервер становится уязвимым

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных удалось выяснить, какие ошибки в конфигурациях встречаются чаще всего. Эта статья прольёт свет на следующие неправильные настройки Nginx:

Отсутствует корневой каталог

Небезопасное использование переменных

Чтение необработанного ответа сервера

Отсутствует корневой каталог

Root-директива указывает корневую папку для Nginx. В приведённом выше примере корневая папка /etc/nginx , что означает, что мы можем получить доступ к файлам в этой папке. В приведенной выше конфигурации нет места для / (location / <. >) , только для /hello.txt . Из-за этого root-директива будет установлена ​​глобально, а это означает, что запросы к / перенаправят вас на локальный путь /etc/nginx .

Такой простой запрос, как GET /nginx.conf , откроет содержимое файла конфигурации Nginx, хранящегося в /etc/nginx/nginx.conf. Если корень установлен в /etc , запрос GET на /nginx/nginx.conf покажет файл конфигурации. В некоторых случаях можно получить доступ к другим файлам конфигурации, журналам доступа и даже зашифрованным учётным данным для базовой аутентификации HTTP.

Из почти 50 000 файлов конфигурации Nginx, которые мы проанализировали, наиболее распространёнными корневыми путями были следующие:

Потерявшийся слеш

При неправильной настройке off-by-slash можно перейти на один шаг вверх по пути из-за отсутствующей косой черты. Orange Tsai поделился информацией об этом в своём выступлении на Blackhat «Нарушение логики парсера!». Он показал, как отсутствие завершающей косой черты в location директиве в сочетании с alias директивой позволяет читать исходный код веб-приложения. Менее известно то, что это также работает с другими директивами, такими как proxy_pass . Давайте разберёмся, что происходит и почему это работает.

Если на Nginx запущена следующая конфигурация, доступная на сервере, можно предположить, что доступны только пути в http://apiserver/v1/ .

Когда запрашивается http://server/api/user , Nginx сначала нормализует URL. Затем он проверяет, соответствует ли префикс /api URL-адресу, что он и делает в данном случае. Затем префикс удаляется из URL-адреса, поэтому остаётся путь /user. Затем этот путь добавляется к URL-адресу proxy_pass , в результате чего получается конечный URL-адрес http://apiserver/v1//user .

Обратите внимание, что в URL-адресе есть двойная косая черта, поскольку директива местоположения не заканчивается косой чертой, а путь URL-адреса proxy_pass заканчивается косой чертой. Большинство веб-серверов нормализуют http://apiserver/v1//user до http://apiserver/v1/user , что означает, что даже с этой неправильной конфигурацией всё будет работать так, как ожидалось, и это может остаться незамеченным.

Эта неправильная конфигурация может быть использована путём запроса http://server/api../ , из-за чего Nginx запросит URL-адрес http://apiserver/v1/../ , который нормализован до http://apiserver/ . Уровень вреда от такой ошибки определяется тем, чего можно достичь, если использовать эту неправильную конфигурацию. Например, это может привести к тому, что статус сервера Apache будет отображаться с URL-адресом http://server/api../server-status , или он может сделать доступными пути, которые не должны быть общедоступными.

Одним из признаков того, что сервер Nginx имеет неправильную конфигурацию, является возврат сервером одинакового же ответа при удалении косой черты в URL-адресе. То есть, если http://server/api/user и http://server/apiuser возвращают один и тот же ответ, сервер может быть уязвимым. Он позволяет отправлять следующие запросы:

Небезопасное использование переменных

Некоторые фреймворки, скрипты и конфигурации Nginx небезопасно используют переменные, хранящиеся в Nginx. Это может привести к таким проблемам, как XSS, обход HttpOnly-защиты, раскрытие информации и в некоторых случаях даже RCE.

SCRIPT_NAME

С такой конфигурацией, как эта:

основная проблема будет заключаться в том, что Nginx отправит интерпретатору PHP любой URL-адрес, заканчивающийся на .php, даже если файл не существует на диске. Это распространённая ошибка во многих конфигурациях Nginx, и об этом говорится в документе «Ловушки и распространенные ошибки», созданном Nginx.

XSS возможен, если PHP-скрипт попытается определить базовый URL на основе SCRIPT_NAME ;

Использование $uri может привести к CRLF-инъекции

Другая неправильная конфигурация, связанная с переменными Nginx, заключается в использовании $uri или $document_uri вместо $request_uri .

$ur i и $document_uri содержат нормализованный URI, тогда как нормализация в Nginx включает URL-декодирование URI. В блоге Volema рассказывалось, что $uri обычно используется при создании перенаправлений в конфигурации Nginx, что приводит к внедрению CRLF.

Пример уязвимой конфигурации Nginx:

Символами новой строки для HTTP-запросов являются r (возврат каретки) и n (перевод строки). URL-кодирование символов новой строки приводит к следующему представлению символов %0d%0a . Когда эти символы включены в запрос типа http://localhost/%0d%0aDetectify:%20clrf на сервер с неправильной конфигурацией, сервер ответит новым заголовком с именем Detectify , поскольку переменная $uri содержит новые URL-декодированные строчные символы.

Произвольные переменные

В некоторых случаях данные, предоставленные пользователем, можно рассматривать как переменную Nginx. Непонятно, почему это происходит, но это встречается не так уж редко, а проверяется довольно-таки сложным путём, как видно из этого отчёта. Если мы поищем сообщение об ошибке, то увидим, что оно находится в модуле фильтра SSI, то есть это связано с SSI.

Одним из способов проверки является установка значения заголовка referer:

Мы просканировали эту неправильную конфигурацию и обнаружили несколько случаев, когда пользователь мог получить значение переменных Nginx. Количество обнаруженных уязвимых экземпляров уменьшилось, что может указывать на то, что уязвимость исправлена.

Чтение необработанного ответа сервера

С proxy_pass Nginx есть возможность перехватывать ошибки и заголовки HTTP, созданные бэкендом (серверной частью). Это очень полезно, если вы хотите скрыть внутренние сообщения об ошибках и заголовки, чтобы они обрабатывались Nginx. Nginx автоматически предоставит страницу пользовательской ошибки, если серверная часть ответит ей. А что происходит, когда Nginx не понимает, что это HTTP-ответ?

Если клиент отправляет недопустимый HTTP-запрос в Nginx, этот запрос будет перенаправлен на серверную часть как есть, и она ответит своим необработанным содержимым. Тогда Nginx не распознает недопустимый HTTP-ответ и просто отправит его клиенту. Представьте себе приложение uWSGI, подобное этому:

И со следующими директивами в Nginx:

proxy_intercept_errors будет обслуживать пользовательский ответ, если бэкенд имеет код ответа больше 300. В нашем приложении uWSGI выше мы отправим ошибку 500, которая будет перехвачена Nginx.

proxy_hide_header почти не требует пояснений; он скроет любой указанный HTTP-заголовок от клиента.

Если мы отправим обычный GET-запрос, Nginx вернёт:

Но если мы отправим неверный HTTP-запрос, например:

То получим такой ответ:

merge_slashes отключены

Для директивы merge_slashes по умолчанию установлено значение «on», что является механизмом сжатия двух или более слешей в один, поэтому /// станет / . Если Nginx используется в качестве обратного прокси и проксируемое приложение уязвимо для включения локального файла, использование дополнительных слешей в запросе может оставить место для его использования. Об этом подробно рассказывают Дэнни Робинсон и Ротем Бар.

Мы нашли 33 Nginx-файла, в которых для параметра merge_slashes установлено значение «off».

Попробуйте сами

Мы создали репозиторий GitHub, где вы можете использовать Docker для настройки своего собственного уязвимого тестового сервера Nginx с некоторыми ошибками конфигурации, обсуждаемыми в этой статье, и попробуйте найти их самостоятельно!

Вывод

Nginx — это очень мощная платформа веб-серверов, и легко понять, почему она широко используется. Но с помощью гибкой настройки вы даёте возможность совершать ошибки, которые могут повлиять на безопасность. Не позволяйте злоумышленнику взломать ваш сайт слишком легко, не проверяя эти распространённые ошибки конфигурации.

Вторая часть будет позднее.

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Источник

When I run uswsgi services WITHOUT running it in emperor mode my django website runs just fine. No matter how I change my configuration I always get the error message my /tmp/uwsgi.log file: «— no python application found, check your startup logs for errors —» I have listed my configuration and error log below:

OS version: Linux raspberrypi 3.6.11+ #538 armv6l GNU/Linux
Django version: 1.6.5
uwsgi version: 2.0.5.1

Virtual environment: /var/www/testbed/env
Project location: /var/www/testbed/project/auth
project tree:

./auth/
|-- __init__.py
|-- __init__.pyc
|-- requirements.txt
|-- settings.py
|-- settings.pyc
|-- urls.py
|-- urls.pyc
|-- wsgi.py
`-- wsgi.pyc

file wsgi.py:

"""
WSGI config for auth project.

It exposes the WSGI callable as a module-level variable named ``application``.

For more information on this file, see
https://docs.djangoproject.com/en/1.6/howto/deployment/wsgi/
"""
    import os, sys, site

    sys.path.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "../../")))
    sys.path.insert(1, os.path.abspath(os.path.join(os.path.dirname(__file__), "../")))
    sys.path.append('/usr/lib/python2.7')
    sys.path.append('/usr/lib/python2.7/dist-packages')

    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "auth.settings")

    from django.core.wsgi import get_wsgi_application
    application = get_wsgi_application()

file /etc/uwsgi/emperor.ini:

[uwsgi]
master = true
emperor = /etc/uwsgi/vassals
logto = /tmp/uwsgi.log

file /etc/uwsgi/vessals/auth.ini:

[uwsgi]
#plugins = python
# Django-related settings
chdir           =/var/www/testbed/project/auth
module          = auth.wsgi:application

# the virtualenv (full path)
home            =/var/www/testbed/env
virtualenv      =/var/www/testbed/env

# process-related settings
enable-threads  = true
pythonpath      = /var/www/testbed/project/auth
#wsgi-file      = /var/www/testbed/project/auth/auth/wsgi.py
env             = DJANGO_SETTINGS_MODULE=auth.settings

mount = /testbed/auth/admin=/var/www/testbed/project/auth/auth/wsgi.py
manage-script-name = true
#route-run = log:SCRIPT_NAME=${SCRIPT_NAME}

# maximum number of worker processes
processes       = 1 #Simple rule is # of cores on machine
# the socket (use the full path to be safe
socket          = /var/www/testbed/project/auth/uwsgi.sock
# ... with appropriate permissions - may be needed
chmod-socket    = 664
# clear environment on exit
vacuum          = true
logto           = /tmp/uwsgi.log

Command being executed listed below:

/var/www/testbed/env/bin/uwsgi --ini /etc/uwsgi/emperor.ini --emperor /etc/uwsgi/vassals/ --http :8000  --plugin python --binary-pathusr/local/bin/uwsgi

Error file /tmp/uwsgi.log:

*** Starting uWSGI 2.0.5.1 (32bit) on [Tue Jun 10 19:06:12 2014] ***
compiled with version: 4.6.3 on 10 June 2014 01:41:52
os: Linux-3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013
nodename: raspberrypi
machine: armv6l
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 
your processes number limit is 3376
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :8000 fd 6
*** starting uWSGI Emperor ***
uwsgi socket 0 bound to TCP address 127.0.0.1:57524 (port auto-assigned) fd 5
Python version: 2.7.3 (default, Mar 18 2014, 05:13:23)  [GCC 4.6.3]
*** has_emperor mode detected (fd: 8) ***
[uWSGI] getting INI configuration from auth.ini
*** Starting uWSGI 2.0.5.1 (32bit) on [Tue Jun 10 19:06:12 2014] ***
compiled with version: 4.6.3 on 09 June 2014 23:07:00
os: Linux-3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013
nodename: raspberrypi
machine: armv6l
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/vassals
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) *** 
your processes number limit is 3376
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /var/www/testbed/project/auth/uwsgi.sock fd 3
Python version: 2.7.3 (default, Mar 18 2014, 05:13:23)  [GCC 4.6.3]
Set PythonHome to /var/www/testbed/env
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x1dca830
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 128512 bytes (125 KB) for 1 cores
*** Operational MODE: single process ***
*** no app loaded. going in full dynamic mode ***
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 23068)
spawned uWSGI worker 1 (pid: 23071, cores: 1)
spawned uWSGI http 1 (pid: 23072)
Python main interpreter initialized at 0x616918
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 128512 bytes (125 KB) for 1 cores
*** Operational MODE: single process ***
added /var/www/testbed/project/auth/ to pythonpath.
WSGI app 0 (mountpoint='') ready in 2 seconds on interpreter 0x616918 pid: 23070 (default app)
mounting /var/www/testbed/project/auth/auth/wsgi.py on /testbed/auth/admin
added /var/www/testbed/project/auth/ to pythonpath.
WSGI app 1 (mountpoint='/testbed/auth/admin') ready in 3 seconds on interpreter 0x9c6218 pid: 23070
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 23070)
Tue Jun 10 19:06:18 2014 - [emperor] vassal auth.ini has been spawned
spawned uWSGI worker 1 (pid: 23073, cores: 1)
Tue Jun 10 19:06:18 2014 - [emperor] vassal auth.ini is ready to accept requests
--- no python application found, check your startup logs for errors ---
[pid: 23071|app: -1|req: -1/1] 192.168.1.6 () {38 vars in 742 bytes} [Tue Jun 10 19:07:11 2014] GET /testbed/auth/admin => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
[pid: 23071|app: -1|req: -1/2] 192.168.1.6 () {36 vars in 626 bytes} [Tue Jun 10 19:07:11 2014] GET /favicon.ico => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
[pid: 23071|app: -1|req: -1/3] 192.168.1.6 () {38 vars in 742 bytes} [Tue Jun 10 19:07:13 2014] GET /testbed/auth/admin => generated 21 bytes in 2 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)
--- no python application found, check your startup logs for errors ---
[pid: 23071|app: -1|req: -1/4] 192.168.1.6 () {36 vars in 626 bytes} [Tue Jun 10 19:07:13 2014] GET /favicon.ico => generated 21 bytes in 1 msecs (HTTP/1.1 500) 2 headers in 83 bytes (0 switches on core 0)

At this point, I’m grasping at straws. Out of all the reading that I have done I can’t see why this keeps rendering the «Internal Server Error.» I may have over looked something that why I’ve finally given in to my pride by posting my sorrows here. Since I’ve gotten this far I really do think that I have overlooked something very small. Any help would be greatly appreciated.

Запуская связку nginx и uwsgi для запуска django проекта, столкнулся с ошибкой 500 на стороне nginx. Я залез в /var/log/nginx/error.log и нашел там конкретное название ошибки:

worker_connections are not enough while connecting to upstream ...

Я пробовал увеличить worker_connections в /etc/nginx/nginx.conf, но при большом значении вылазить ошибка:

socket() failed (24: To many open files)

Пробовал решить это с помощью создания в том же /etc/nginx/nginx.conf параметра — worker_limit_nofile, но это возвращает ошибку worker_connections are not enough while connecting to upstream. Дальнейшая игра с увеличением, уменьшением этих двух параметров (worker_connections и worker_limit_nofile) ничего не дает. Мне лишь выкидывает то первую ошибку, то вторую.

В общем, пожалуйста, помогите избавиться от ошибок. Благодарю заранее! (прилагаю конфиги)

  GNU nano 4.8                 /etc/nginx/nginx.conf
user www-data;
worker_processes auto;
#bilo auto
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
worker_rlimit_nofile 10000;
events {
        worker_connections 20000;
        # 768 bilo tyt
        # multi_accept on;
}
...

  GNU nano 4.8           /etc/uwsgi/apps-enabled/myapp.ini
[uwsgi]
chdir = /root/eva/lawyer
env = DJANGO_SETTINGS_MODULE= lawyer.settings.production
wsgi-file = lawyer/wsgi.py
#module = lawyer.uwsgi:application
workers = 1
max-requests = 5000
#plugins-dir=/usr/lib/uwsgi/plugins/
#plugins = python3
#virtualenv = /root/eva/venv
home = /root/eva/venv
processes = 5
threads = 2
master = true
die-on-term = true
socket = /run/sedova.sock
chmod-socket = 666
vacuum = true
uid = www-data
gui = www-data

GNU nano 4.8 /etc/nginx/conf.d/my_app.conf

server {
        listen 82;
        server_tokens off;
        server_name 185.46.8.164;
    
        #root /var/www/
        location / {
            include uwsgi_params;
            uwsgi_pass unix:///run/uwsgi/app/myapp/socket;
            #
            try_files $uri $uri/ =404;
            #
            proxy_pass http://185.46.8.164:82;
            proxy_set_header X-Forwarded-Host $server_name;
            proxy_set_header X-Real-IP $remote_addr;
            add_header P3P 'CP="ALL DSP COR PSAa PSDa OUR NOR ONL UNI COM NAV"';
            add_header Access-Control-Allow-Origin *;
        }...

VPS server on Linux (ubuntu 20.04)
nginx version: nginx/1.18.0 (Ubuntu)
uwsgi 2.0.20
python3
django 3.2.8

Вернуться на верх