2013-02-28 7 views
12

Przygotowuję się do użycia nginx/uwsgi z kolbą do strony, którą rozwijam, ale mam problemy. Uwaga: sama strona działa doskonale przy użyciu debugowania kolby: 5000 portów, ale teraz chcę rozpocząć produkcję. Aby wyjaśnić, co zrobiłem.Może uruchamiać tylko uwsgi z korzeniem

Jest to Linode ubuntu serwer 12.04LTS, zainstalowałem go tak:

# 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 

Potem określone skonfigurować wszystko, ale ja już popaść w kłopoty z uwsgi (nieważne nginx, który będzie . następnym krokiem

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 

Jednakże jeśli uruchomię go uzyskać:

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. 

więc mogę operacja odłączenia nie jest dozwolona, ​​a adres powiązania jest już w użyciu (obok błędu python_plugin, którego również nie mam pojęcia, jak to rozwiązać!). Jeśli działam jako sudo, wygląda na to, że działa poprawnie ->

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 

Czy ktoś może mi pomóc? Jak www-data jest w grupie www-data i prowadzi go, próbowałem kilka rzeczy:

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 

Ale to naprawdę nie pomogło. Próbowałem też portu TCP zamiast unix/run/uwsgi/app/port, które nie miało żadnej różnicy ... To doprowadza mnie do szału :(Mam nadzieję, że ktoś ma pojęcie o tym, co się tutaj dzieje:

poważaniem,

wapiennym

edit: po serwerze restart nadal daje się erro ale inną:

[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] 

Odpowiedz

6

Ok, po późniejszej edycji Sprawdziłem katalogów i gniazdo katalog nie istniał (już), chudnę k to miało związek z oryginalną instalacją apt-get z moją późniejszą instalacją pip ... nadal występuje problem z wtyczką Pythona, ale sprawdzi, czy jest to konieczne dla nginxa, czy też będzie działać bez niego ... 8 godzin pracy ponad resecie d'oh;)

@bearrito: w końcu mogę umieścić gniazdo w katalogu tmp, aby uniknąć problemów z prawami:

<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> 

mam nadzieję, że to pomoże!

+1

Mały później komentarz: plugin python (który jest w każdym google przykład) nie wydaje się już konieczne w nowszych wersjach. W końcu to naprawdę działa łatwiej i po wyjęciu z pudełka, niż myślałem wcześniej! – Carst

+0

Czy możesz odgadnąć bardziej szczegółowo, co pociąga za sobą poprawka? Jestem w tym samym scenariuszu, ale nie byłem w stanie odcyfrować czegoś odtwarzalnego w moim przypadku. – bearrito

+0

Edytowałeś to, co zrobiłem! Ponadto: moje ograniczenia pamięci robotniczej są naprawdę, więc nie kopiujmy tego :) (ma to związek z ciężkim procesem analitycznym) – Carst

17

To był konsekwentnie mój wynik nr 1 w google, a ta strona była dla mnie względnie nieprzydatna, więc zamierzam dodać moją odpowiedź, mimo że jest to dość oczywiste z perspektywy czasu.

Mój problem polegał na problemie z prawem dostępu do mojego gniazda statystyk. Jeśli zmienisz parametry uid lub gid w konfiguracji uWSGI, upewnij się, że albo chmod lub rm wszystkie twoje stare gniazda/pidy i ich foldery nadrzędne.

+0

Cześć, przykro mi to słyszeć, ale to ci nie pomogło. to jest to, co mam na myśli z moim "W końcu umieszczam gniazdo w katalogu tmp, aby uniknąć problemów z prawami" uwaga, ale masz rację, że mogło być trochę mniej tajemnicze. Problem wynikał również z tego, że miałem dwa problemy w tym samym czasie, drugi to: http://stackoverflow.com/questions/15936413/pip-installed-uwsgi-python-plugin-so-error – Carst

+3

Przepraszamy , nie chciał zaatakować twojej odpowiedzi, tylko dodać do niej, gdy następnym razem skończę na tej stronie. IMHO, wiadomości dziennika z uWSGI są całkowicie pomocne w rozwiązywaniu tego problemu. – pnovotnak

+1

Nie martw się, nie widziałem tego w ten sposób. Będę edytować odpowiedź, aby pomóc ludziom lepiej. Zasadniczo problem polega na tym, że możesz mieć dwa osobne problemy w tym samym czasie (problem z wtyczką Pythona + problem z gniazdem praw), co również dawało mi ból głowy i jest powodem, dla którego oryginalna odpowiedź powyżej jest tak szeroka. – Carst

0

Dla mnie rozwiązaniem było usunąć /var/run/uwsgi/.sock i

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

lub wszędzie tam, gdzie są pliki uwsgi.

7

W moim przypadku próbowałem umieścić plik .sock w katalogu /vagrant, który jest zamontowanym na maszynie folderem wirtualnego pudełka i nie jest dobry na wiele więcej niż czytanie i zapisywanie.

Umieść plik .sock zewnątrz z VirtualBox mocowanie punkt najlepiej w /tmpFHS mówi: /var/run

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

+0

To było naprawdę przydatne dla mnie. – cjauvin

+0

To właśnie tutaj powinna być odpowiedź – Jeremy