può essere eseguito solo uwsgi con radice

mi preparo a usare nginx/uwsgi con la boccetta per un sito web che sto sviluppando, ma sto correndo in problemi. NB il sito web funziona alla grande usando il debug di flask: 5000 port, ma ora voglio entrare in produzione. Per spiegare cosa ho fatto.può essere eseguito solo uwsgi con radice

Si tratta di un server 12.04LTS linode ubuntu, ho installato in questo modo:

# install nginx 
sudo apt-get install python-software-properties 
sudo add-apt-repository ppa:nginx/stable 
sudo apt-get update 
sudo apt-get upgrade --show-upgraded 
sudo apt-get install nginx-full 
# installing uwsgi 
sudo apt-get install build-essential python-dev libxml2-dev 
sudo apt-get install libc6 libexpat1 libgd2-xpm libgeoip1 libpam0g libpcre3 libssl1.0.0 libxml2 libxslt1.1 zlib1g 
sudo pip install uwsgi 
# python basics 
sudo apt-get install python-pip build-essential python-dev 
sudo pip install virtualenv 
sudo pip install virtualenvwrapper 
sudo mkdir -p /srv/www/li/ 
cd /srv/www/li/ 
virtualenv venv 
source /srv/www/li/venv/bin/activate 
pip install flask

Poi ho deciso di configurare tutto, ma ho già incorrere in guai con uwsgi (non importa Nginx, che sarà il . passo successivo

sudo nano /etc/uwsgi/apps-available/li.xml 

    <uwsgi> 
    <plugin>python</plugin> 
    <socket>/run/uwsgi/app/li.socket</socket> 
    <chmod-socket>666</chmod-socket> 
    <chdir>/srv/www/li</chdir> 
    <pythonpath>/srv/www/li</pythonpath> 
    <virtualenv>/srv/www/li/venv</virtualenv> 
    <module>li</module> 
    <wsgi-file>/srv/www/li/li.py</wsgi-file> 
    <callable>app</callable> 
    <master/> 
    <processes>4</processes> 
    <harakiri>60</harakiri> 
    <reload-mercy>8</reload-mercy> 
    <cpu-affinity>1</cpu-affinity> 
    <stats>/tmp/stats.socket</stats> 
    <max-requests>2000</max-requests> 
    <limit-as>512</limit-as> 
    <reload-on-as>256</reload-on-as> 
    <reload-on-rss>192</reload-on-rss> 
    <no-orphans/> 
    <vacuum/> 
</uwsgi> 

sudo ln -s /etc/uwsgi/apps-available/li.xml /etc/uwsgi/apps-enabled/li.xml

Tuttavia, se l'eseguo, ottengo:

uwsgi --xml /etc/uwsgi/apps-enabled/li.xml 

[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml 
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755] 
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!! 
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 16:30:53 2013] *** 
compiled with version: 4.6.3 on 28 February 2013 12:38:22 
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013 
nodename: demo 
machine: x86_64 
clock source: unix 
detected number of CPU cores: 4 
current working directory: /run/uwsgi/app 
detected binary path: /usr/local/bin/uwsgi 
your processes number limit is 63594 
limiting address space of processes... 
your process address space limit is 536870912 bytes (512 MB) 
your memory page size is 4096 bytes 
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024 
lock engine: pthread robust mutexes 
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3 
Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3] 
Set PythonHome to /srv/www/li/venv 
*** Python threads support is disabled. You can enable it with --enable-threads *** 
Python main interpreter initialized at 0xa86e20 
your server socket listen backlog is limited to 100 connections 
mapped 362120 bytes (353 KB) for 4 cores 
*** Operational MODE: preforking *** 
added /srv/www/li/ to pythonpath. 
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId strings in 0.8, set DBRef=True if this isn't desired 
    warnings.warn(msg, FutureWarning) 
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa86e20 pid: 14934 (default app) 
*** uWSGI is running in multiple interpreter mode *** 
spawned uWSGI master process (pid: 14934) 
spawned uWSGI worker 1 (pid: 14940, cores: 1) 
mapping worker 1 to CPUs: 0 
spawned uWSGI worker 2 (pid: 14941, cores: 1) 
mapping worker 2 to CPUs: 1 
spawned uWSGI worker 3 (pid: 14942, cores: 1) 
mapping worker 3 to CPUs: 2 
spawned uWSGI worker 4 (pid: 14943, cores: 1) 
unlink(): Operation not permitted [core/socket.c line 109] 
bind(): Address already in use [core/socket.c line 141] 
...brutally killing workers... 
mapping worker 4 to CPUs: 3 
VACUUM: unix socket /run/uwsgi/app/li.socket removed.

così ottengo l'operazione di scollegamento non è consentita e l'indirizzo di bind è già in uso (accanto all'errore python_plugin di cui anch'io non ho idea di come risolverlo!). Se corro come sudo, sembra funzionare bene ->

sudo uwsgi --xml /etc/uwsgi/apps-enabled/li.xml 

[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml 
open("./python_plugin.so"): No such file or directory [core/utils.c line 4755] 
!!! UNABLE to load uWSGI plugin: ./python_plugin.so: cannot open shared object file: No such file or directory !!! 
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 15:47:41 2013] *** 
compiled with version: 4.6.3 on 28 February 2013 12:38:22 
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013 
nodename: demo 
machine: x86_64 
clock source: unix 
detected number of CPU cores: 4 
current working directory: /run/uwsgi 
detected binary path: /usr/local/bin/uwsgi 
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 63594 
limiting address space of processes... 
your process address space limit is 536870912 bytes (512 MB) 
your memory page size is 4096 bytes 
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024 
lock engine: pthread robust mutexes 
uwsgi socket 0 bound to UNIX address /run/uwsgi/app/li.socket fd 3 
Python version: 2.7.3 (default, Aug 1 2012, 05:25:23) [GCC 4.6.3] 
Set PythonHome to /srv/www/li/venv 
*** Python threads support is disabled. You can enable it with --enable-threads *** 
Python main interpreter initialized at 0x1fc9d00 
your server socket listen backlog is limited to 100 connections 
mapped 362120 bytes (353 KB) for 4 cores 
*** Operational MODE: preforking *** 
added /srv/www/li/ to pythonpath. 
/srv/www/li/venv/local/lib/python2.7/site-packages/mongoengine/fields.py:744: FutureWarning: ReferenceFields will default to using ObjectId strings in 0.8, set DBRef=True if this isn't desired 
    warnings.warn(msg, FutureWarning) 
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x1fc9d00 pid: 14755 (default app) 
*** uWSGI is running in multiple interpreter mode *** 
spawned uWSGI master process (pid: 14755) 
spawned uWSGI worker 1 (pid: 14761, cores: 1) 
mapping worker 1 to CPUs: 0 
spawned uWSGI worker 2 (pid: 14762, cores: 1) 
mapping worker 2 to CPUs: 1 
spawned uWSGI worker 3 (pid: 14763, cores: 1) 
mapping worker 3 to CPUs: 2 
spawned uWSGI worker 4 (pid: 14764, cores: 1) 
*** Stats server enabled on /tmp/stats.socket fd: 16 *** 
mapping worker 4 to CPUs: 3

Qualcuno può aiutarmi per favore? Come www-data è nel gruppo www-data e lui lo esegue, ho provato alcune cose:

sudo usermod -a -G www-data $USER 
sudo chown -R $USER:www-data /srv/www/li 
sudo chmod -R g+r+w+x /srv/www/li 
sudo chown -R $USER:www-data /etc/uwsgi/apps-enabled 
sudo chmod -R g+r+w+x /etc/uwsgi/apps-enabled 
sudo chown -R $USER:www-data /run/uwsgi/app 
sudo chmod -R g+r+w+x /run/uwsgi/app

ma che in realtà non ha aiutato neanche. Ho provato anche una porta TCP invece del unix/run/uwsgi/app/porto che non ha fatto alcuna differenza o ... Questo mi sta facendo impazzire :(Spero che qualcuno ha un indizio su quello che sta succedendo qui.

Cordiali saluti,

Carst

edit: dopo un server di riavvio dà ancora un erro, ma uno diverso:

[email protected]:~$ uwsgi --xml /etc/uwsgi/apps-enabled/li.xml 
[uWSGI] parsing config file /etc/uwsgi/apps-enabled/li.xml 
*** Starting uWSGI 1.4.6 (64bit) on [Thu Feb 28 18:47:36 2013] *** 
compiled with version: 4.6.3 on 28 February 2013 12:38:22 
os: Linux-3.7.10-x86_64-linode30 #1 SMP Wed Feb 27 14:29:31 EST 2013 
nodename: demo 
machine: x86_64 
clock source: unix 
detected number of CPU cores: 4 
current working directory: /home/geoadmin 
detected binary path: /usr/local/bin/uwsgi 
your processes number limit is 63594 
limiting address space of processes... 
your process address space limit is 536870912 bytes (512 MB) 
your memory page size is 4096 bytes 
*** WARNING: you have enabled harakiri without post buffering. Slow upload could be rejected on post-unbuffered webservers *** 
detected max file descriptor number: 1024 
lock engine: pthread robust mutexes 
bind(): No such file or directory [core/socket.c line 141]

fonte

2013-02-28 Carst

Ok, dopo la modifica in seguito ho controllato le directory e la presa la directory non esisteva più (più); k ha avuto a che fare con l'installazione originale di apt-get contro la mia successiva installazione di pip ... ha ancora il problema con il plugin python ma controllerà se è necessario per nginx o se funzionerà senza di esso ... 8 ore di lavoro nel corso di un reset, d'oh;)

@bearrito: alla fine ho messo la presa nella directory tmp per evitare problemi di diritti:

<uwsgi> 
     <uid>www-data</uid> 
     <gid>www-data</gid> 
    <plugin>python</plugin> 
    <socket>/tmp/li.socket</socket> 
    <chmod-socket>666</chmod-socket> 
    <chdir>/srv/www/li</chdir> 
    <pythonpath>/srv/www/li</pythonpath> 
    <virtualenv>/srv/www/li/venv</virtualenv> 
    <module>li</module> 
    <wsgi-file>/srv/www/li/li.py</wsgi-file> 
    <callable>app</callable> 
    <master/> 
    <processes>2</processes> 
    <pidfile>/tmp/li.pid</pidfile> 
    <harakiri>120</harakiri> 
    <reload-mercy>8</reload-mercy> 
    <cpu-affinity>1</cpu-affinity> 
    <stats>/tmp/stats.socket</stats> 
    <max-requests>2000</max-requests> 
    <limit-as>2048</limit-as> 
    <reload-on-as>2048</reload-on-as> 
    <reload-on-rss>1024</reload-on-rss> 
    <no-orphans/> 
    <vacuum/> 
</uwsgi>

Spero che questo aiuta!

fonte

2013-02-28 18:58:55 Carst

Piccolo commento tardi: il plugin python (che è in ogni esempio Googled) non sembra più necessario nelle versioni più recenti. Quindi alla fine funziona davvero più facile e fuori dalla scatola di quanto pensassi prima! – Carst

Riesci un po 'più esplicito in ciò che la tua correzione comportava? Sono nello stesso identico scenario ma non ero in grado di decifrare qualcosa riproducibile nel mio caso. – bearrito

Modificato con quello che ho fatto! Inoltre: i miei limiti di memoria del lavoro sono davvero, quindi non copiarlo :) (ha a che fare con un pesante processo di analisi) – Carst

Questo era costantemente il mio risultato n. 1 su google, e questa pagina era relativamente poco utile per me, quindi aggiungerò la mia risposta, anche se è abbastanza ovvio in retrospettiva.

Il mio problema era un problema di autorizzazioni con il mio socket stats. Se si cambia uid o gid parametri tuo uWSGI di configurazione, assicurarsi che si sia chmod o rm tutti i tuoi vecchi zoccoli/PID, e le loro cartelle principali.

fonte

2013-10-03 22:19:33 pnovotnak

Ciao, mi spiace di sentire che non ti ha aiutato. è quello che intendo con il mio "Alla fine ho messo il socket nella directory tmp per evitare problemi con i diritti", ma hai ragione che avrebbe potuto essere un po 'meno criptico. il problema è stato causato anche dal fatto che avevo due problemi contemporaneamente, l'altro era: http://stackoverflow.com/questions/15936413/pip-installed-uwsgi-python-plugin-so-error – Carst

Spiacente , non intendevo attaccare la tua risposta, aggiungo solo per la prossima volta che finisco su questa pagina. IMHO, i messaggi di log di uWSGI sono del tutto inutili nell'affrontare questo problema. – pnovotnak

Non preoccuparti, non l'ho visto così. Modificherò la risposta per aiutare meglio le persone. Fondamentalmente il problema è che puoi avere due problemi separati allo stesso tempo (problema del plugin python + problema del socket dei diritti) che mi ha anche dato un forte mal di testa ed è la ragione per cui la risposta originale sopra è così ampia – Carst

Per me la soluzione era quella di rimuovere /var/run/uwsgi/.sock e

chmod 775 /var/run/uwsgi 
chmod 777 /var/log/uwsgi

o dove i file sono uwsgi.

fonte

2015-01-23 11:00:28 Soda

Nel mio caso stavo cercando di posizionare il file .sock nella directory /vagrant, che è una cartella montata su macchina di virtual box e non va bene per molto più che letture e scritture.

Inserire il file .sock al di fuori di un virtualbox montaggio punti preferibilmente in ~~/tmp~~ Il FHS dice: /var/run

Rif: https://stackoverflow.com/a/7580524/1695680

fonte

2015-10-03 06:58:13 ThorSummoner

Questo mi è stato molto utile. – cjauvin

Questo qui dovrebbe essere la risposta – Jeremy

può essere eseguito solo uwsgi con radice

risposta

Problemi correlati