Не уверен, где я ошибаюсь, все, что я получаю, - это плохой шлюз 502. (IP-адрес сервера 104.197.13.112) Код для всех файлов конфигурации и базового приложения находится в репозитории github. репозиторий github
Кажется, что nginx запускается правильно, uwsgi - нет, и я думаю, что моя проблема связана с моими настройками uwsgi и uwsgi.ini. Также не в журнале ниже, мой виртуальный env - это python 3.5 и ниже отчетов об ошибках 3.4.2. В моем виртуальном окружении установлен uwsgi. (Обновление, я установил uwsgi в моем виртуальном env для запуска виртуальным env, а не системным python, путем привязки uwsgi в / usr / bin / uwsgi к uwsgi в env.) Журнал ниже отражает это, но ошибка в остальном такая же
Журнал показывает
(testenv)root@co-data-nginx-1:/# tail /var/log/uwsgi/app/flasktest.log
Wed Jan 13 03:39:39 2016 - uwsgi socket 1 bound to UNIX address /tmp/flasktest.sock fd 5
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Wed Jan 13 03:39:39 2016 - Python version: 3.5.1 |Continuum Analytics, Inc.| (default, Dec 7 2015, 11:16:01) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
Wed Jan 13 03:39:39 2016 - Set PythonHome to /var/www/flasktest/testenv
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'
uwsgi does not start.
uwsgi не запускается
(testenv)root@co-data-nginx-1:/# service uwsgi restart
Job for uwsgi.service failed. See 'systemctl status uwsgi.service' and 'journalctl -xn' for details.
(testenv)root@co-data-nginx-1:/# journalctl -xn
-- Logs begin at Tue 2016-01-12 23:46:30 UTC, end at Wed 2016-01-13 03:58:07 UTC. --
Jan 13 03:58:04 co-data-nginx-1 systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
-- Subject: Unit uwsgi.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has begun starting up.
Jan 13 03:58:04 co-data-nginx-1 uwsgi[7065]: Starting app server(s): uwsgi -> ! failed!
Jan 13 03:58:04 co-data-nginx-1 systemd[1]: uwsgi.service: control process exited, code=exited status=1
Jan 13 03:58:04 co-data-nginx-1 systemd[1]: Failed to start LSB: Start/stop uWSGI server instance(s).
-- Subject: Unit uwsgi.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has failed.
--
-- The result is failed.
Jan 13 03:58:04 co-data-nginx-1 systemd[1]: Unit uwsgi.service entered failed state.
Jan 13 03:58:06 co-data-nginx-1 systemd[1]: Starting LSB: Start/stop uWSGI server instance(s)...
-- Subject: Unit uwsgi.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has begun starting up.
Jan 13 03:58:07 co-data-nginx-1 uwsgi[7207]: Starting app server(s): uwsgi -> ! failed!
Jan 13 03:58:07 co-data-nginx-1 systemd[1]: uwsgi.service: control process exited, code=exited status=1
Jan 13 03:58:07 co-data-nginx-1 systemd[1]: Failed to start LSB: Start/stop uWSGI server instance(s).
-- Subject: Unit uwsgi.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit uwsgi.service has failed.
--
-- The result is failed.
Jan 13 03:58:07 co-data-nginx-1 systemd[1]: Unit uwsgi.service entered failed state.
Попробуйте выполнить тест @gf_, запустите:
uwsgi --ini /etc/uwsgi/apps-enabled/flasktest.ini
Я получаю результат ниже, это выглядит хорошо, но (помните, что я работаю как root), если я вхожу в систему как другой пользователь, я могу запустить только указанную выше строку, если я задую sudo. Если я добавлю sudo, это не сработает, вы получите ту же ошибку, что и в журнале uwsgi.
(testenv)root@co-data-nginx-1:/etc/uwsgi/apps-enabled# uwsgi --ini flasktest.ini
[uWSGI] getting INI configuration from flasktest.ini
*** Starting uWSGI 2.0.12 (64bit) on [Wed Jan 13 21:54:35 2016] ***
compiled with version: 4.9.2 on 12 January 2016 23:28:38
os: Linux-3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u2 (2016-01-02)
nodename: co-data-nginx-1
machine: x86_64
clock source: unix
detected number of CPU cores: 1
current working directory: /etc/uwsgi/apps-enabled
detected binary path: /var/www/flasktest/testenv/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) ***
chdir() to /var/www/flasktest
your processes number limit is 14779
your memory page size is 4096 bytes
detected max file descriptor number: 65536
VirtualHosting mode enabled.
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to UNIX address /tmp/flasktest.sock fd 3
Python version: 3.5.1 |Continuum Analytics, Inc.| (default, Dec 7 2015, 11:16:01) [GCC 4.4.7 20120313 (Red Hat 4.4.7-1)]
Set PythonHome to /var/www/flasktest/testenv
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x192cb40
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 436560 bytes (426 KB) for 5 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x192cb40 pid: 17933 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 17933)
spawned uWSGI worker 1 (pid: 17935, cores: 1)
spawned uWSGI worker 2 (pid: 17936, cores: 1)
spawned uWSGI worker 3 (pid: 17937, cores: 1)
spawned uWSGI worker 4 (pid: 17938, cores: 1)
spawned uWSGI worker 5 (pid: 17939, cores: 1)
В / etc / uwsgi / apps-avalible (enabled) у меня есть.
(testenv)root@co-data-nginx-1:/# cat /etc/uwsgi/apps-enabled/flasktest.ini
# To be put in /etc/uwsgi/apps-available and lnked to the apps-enabled
# mv /var/www/flasktest/config/flasktest.ini /etc/uwsgi/apps-available/
# and simlink into
# ln -s /etc/uwsgi/apps-available/flasktest /etc/uwsgi/apps-enabled
[uwsgi]
module = testapp
callable = app
vhost = true
venv = /var/www/flasktest/testenv
chdir = /var/www/flasktest
master = true
processes = 5
socket = /tmp/%n.sock
vacuum = true
die-on-term = true
И наконец, вот настройка nginx, опять же все это в репозитории github.
(testenv)root@co-data-nginx-1:/# cat /etc/nginx/sites-available/flasktest
# rm /etc/nginx/sites-available/default
# rm /etc/nginx/sites-enabled/default
# mv /var/www/flasktest/config/flasktest /etc/nginx/sites-available/
# and simlink into
# ln -s /etc/nginx/sites-available/flasktest /etc/nginx/sites-enabled
# now test setup
# nginx -t
# If it passes run
# service nginx restart
server {
listen 80;
server_tokens off;
# ip address or domain
# server_name www.mysite.com mysite.com
server_name 104.197.13.112;
location /static {
alias /var/www/flasktest/static;
}
location / {
include uwsgi_params;
uwsgi_pass unix:///tmp/flasktest.sock;
include uwsgi_params;
}
журналы nginx
2016/01/13 02:34:03 [error] 4417#0: *2 connect() to unix:///tmp/flasktest.sock failed (111: Connection refused) while connecting to upstream, client: 24.52.34.170, server: 104.197.13.112, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/flasktest.sock:", host: "104.197.13.112"
2016/01/13 02:34:04 [error] 4417#0: *2 connect() to unix:///tmp/flasktest.sock failed (111: Connection refused) while connecting to upstream, client: 24.52.34.170, server: 104.197.13.112, request: "GET /favicon.ico HTTP/1.1", upstream: "uwsgi://unix:///tmp/flasktest.sock:", host: "104.197.13.112", referrer: "http://104.197.13.112/"
Пошли...
/var/www/flasktest/uwsgi.ini
, вам это не нужно.uwsgi
:
socket
директива в вашем uwsgi.ini
к /tmp/%n.sock
. %n
будет оцениваться по имени файла конфигурации без расширения. uwsgi
работать если запускать? Загляните внутрь журналов; если вы обнаружите ошибки, опубликуйте их.Nginx
:
uwsgi_pass
директива к uwsgi_pass unix:///tmp/flasktest.sock
и вставить include uwsgi_params;
на следующей строке./
и /static
config, чтобы убедиться, что они работают должным образом. В его нынешнем виде /
будет попадать по всем запросам, включая /static
, поэтому они будут обслуживаться вашим сервером, что нецелесообразно, учитывая, что обслуживаемые файлы статические, а не динамические.