Я пытаюсь получить стек LNP [Linux Nginx Python] (это вообще что-то? Хех), но у меня возникают некоторые трудности.
Многие сообщения в блогах и документация по этому поводу, похоже, вращаются вокруг использования Upstart для управления процессом uWSGI, что было бы хорошо, но я заметил, что пакеты, установленные с помощью сценария init.d и некоторых каталогов конфигурации в /etc/uwsgi/{apps-enabled,apps-available}
. Итак, очевидно, что есть способ сделать это лучше.
У меня есть несколько файлов конфигурации (см. Ниже), но я не могу запустить процесс uwsgi, запуск сценария init.d ничего не делает, сообщает об успехе, но молча терпит неудачу (даже без журнала).
Когда я запускаю uWSGI напрямую, я получаю следующее:
% sudo uwsgi -i /etc/uwsgi/apps-enabled/site.ini
tmp = /
[uWSGI] getting INI configuration from /etc/uwsgi/apps-enabled/site.ini
/usr/lib/uwsgi/plugins/python27_plugin.so
Также стоит отметить, что при попытке доступа к сайту выдается ошибка:
% cat logs/error.log
2012/01/08 23:26:12 [crit] 9167#0: *13 connect() to unix://tmp/site.sock failed (2: No such file or directory) while connecting to upstream, client: 60.241.99.33, server: mysite.com, request: "GET / HTTP/1.1", upstream: "uwsgi://unix://tmp/site.sock:", host: "mysite.com"
Конфигурация uWSGI
% cat /etc/uwsgi/apps-enabled/config.ini
[uwsgi]
uid = www-data
gid = www-data
home = /srv/www/site/myapp
socket = /tmp/site.sock
pythonpath = /srv/www/site/virtualenvs/default
harakiri = 60
daemonize = /srv/www/site/logs/uwsgi.log
plugins = http,python
Конфигурация Nginx
% cat /etc/nginx/sites-enabled/mysite.com
server {
listen 80;
server_name mysite.com;
access_log /srv/www/site/logs/access.log;
error_log /srv/www/site/logs/error.log;
root /srv/www/site/public_html;
index index.html index.htm;
location / {
uwsgi_pass unix:///tmp/site.sock;
include uwsgi_params;
}
location ~ /\. {
access_log off;
log_not_found off;
deny all;
}
location ~* \.(jpg|jpeg|gif|png|css|js|ico|xml)$ {
access_log off;
log_not_found off;
expires 360d;
}
}
я использую
% dpkg --get-selections | grep uwsgi
libapache2-mod-uwsgi install
uwsgi install
uwsgi-core install
uwsgi-plugin-http install
uwsgi-plugin-python install
% dpkg --get-selections | grep nginx
nginx-common install
nginx-extras install
nginx-full deinstall
Некоторая информация о версии
% nginx -V
nginx: nginx version: nginx/1.0.5
nginx: TLS SNI support enabled
nginx: configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-debug --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_perl_module --with-http_random_index_module --with-http_realip_module --with-http_secure_link_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-sha1=/usr/include/openssl --with-md5=/usr/include/openssl --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-development-kit --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-lua --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-http-push --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-upload-progress --add-module=/build/buildd/nginx-1.0.5/debian/modules/nginx-secure-download
% uwsgi --version
uWSGI 0.9.8.1-debian
Глядя на ваш error.log, это может быть проблема с разрешениями с unix: ///tmp/site.sock, в вашем uwsgi conf.ini вы можете использовать chmod-сокет вариант, описанный здесь: uwsgi docs
У вас есть демонизированный сервер приложений uwsgi с /srv/www/site/logs/uwsgi.log в качестве журнала. Журнал uwsgi должен содержать информацию о том, почему изначально не удалось создать файл sock.
Я знаю, что это довольно поздно, но после небольшого поиска в Google Если ваш сокет не создается, вы, возможно, забыли создать ссылку из ./apps-enabled
каталог в ./apps-available
sudo ln -s /etc/uwsgi/apps-available/mysite.ini /etc/uwsgi/apps-enabled/mysite.ini
$ cat /etc/uwsgi/apps-enabled/README
читает
Некоторые файлы, находящиеся в этом каталоге, обрабатываются скриптом uWSGI init.d как файлы конфигурации uWSGI.
При загрузке системы для каждого файла конфигурации новый экземпляр демона uWSGI запускается с дополнительной опцией. Название этой опции основано на расширении файла конфигурации. Путь к файлам конфигурации передается как значение параметра.
См. Более подробную информацию по адресу: * /usr/share/doc/uwsgi/README.Debian.gz * / etc / default / uwsgi
конечно, вам не нужно перезагружать систему, вы можете просто sudo service uwsgi restart
Примечание: Я только что понял, что вы используете 11.10, а я 12.04, так что это может не сработать для вас.
Я всегда предлагаю новым пользователям начинать с официального краткого руководства, поскольку uWSGI построен с идеей (которая может вам понравиться или нет), что каждое приложение отличается от других, и каждое требует определенной настройки. Таким образом, его настройка без полного понимания основных концепций может быть настоящей (реальной) PITA.
Кстати, похоже, что у вас почти полностью рабочая конфигурация, я заметил следующие неправильные вещи:
Директива uwsgi_pass в nginx должна быть
uwsgi_pass unix: /tmp/site.sock
(без дополнительных слэшей)
Вам не нужно загружать плагин http в экземпляр uWSGI, поскольку nginx изначально использует протокол uwsgi.
Убедитесь, что / srv / www / site / logs доступен для записи пользователем www-data и, наконец (в качестве предложения), начните использовать сокеты TCP, поскольку они не требуют разрешений и могут быть легко проверены с помощью такого инструмента, как netstat.
Еще одно замечание: вы можете попробовать запустить uwsgi вручную с помощью «uwsgi configfile» после удаления опции «daemonize». Таким образом вы можете проверить свой терминал на наличие ошибок.