2012-06-22 14 views
10

Po pierwsze mam wiele instancji Django, które działają i działają w ten sposób.Gunicorn i Django z Upstart i Nginx

W każdym projekcie mam skrypt script.sh który rozpoczyna gunicorn itp .:

#!/bin/bash 
    set -e 
    LOGFILE=/var/log/gunicorn/app_name.log 
    LOGDIR=$(dirname $LOGFILE) 
    NUM_WORKERS=3 
    # user/group to run as 
    USER=root 
    GROUP=root 
    PORT=8060 
    IP=127.0.0.1 
    cd /var/www/webapps/app_name 
    source ../bin/activate 
    test -d $LOGDIR || mkdir -p $LOGDIR 
    exec /var/www/webapps/bin/gunicorn_django -b $IP:$PORT -w $NUM_WORKERS \ 
    --user=$USER --group=$GROUP --log-level=debug --log-file=$LOGFILE 2>>$LOGFILE 

Po uruchomieniu tego skryptu z linii poleceń z bash script.sh, witryna działa idealnie, więc Nginx jest ustawiony prawidłowo.

Po uruchomieniu usługi usługa nazwa_aplikacji uruchamia się i uruchamia aplikację, a następnie zatrzymuje się. Nie zapisuje nawet do pliku dziennika.

To app_name.conf plik w /etc/init/app_name.conf:

description "Test Django instance" 
start on runlevel [2345] 
stop on runlevel [06] 
respawn 
respawn limit 10 5 
exec /var/www/webapps/app_name/script.sh 

Więc jaki jest problem? Ponieważ działa z wiersza poleceń działa, ale nie robi to z wyprzedzeniem. I nie wiem, gdzie można zobaczyć, co jest nie tak?

+0

Cholera, to jest frustrujące, jestem pewien, że jestem ślepy czy coś takiego i nie widzę problemu! – Harry

+0

Nawet przy uruchomieniu tej komendy fomr gunicorn_django -b $ IP: $ PORT -w $ NUM_WORKERS \ --user = $ USER --group = $ GROUP --log-level = debug --log-file = $ LOGFILE 2 >> $ LOGFILE wszystko działa. Musi być tak, że problem zaczyna się od paryskiej? – Harry

Odpowiedz

15

Cóż, wymyśliłem to. Jeśli ktokolwiek kiedykolwiek napotka na coś takiego ...

To w zasadzie brak wiedzy na temat skryptów powłoki, które mnie powstrzymywały.

Po skomentowaniu każdej linii pliku skryptowego znalazłem problem z linią: źródło ../bin/activate i wszystko po tym.

Problem polegał na tym, że miał 2 spacje przed sobą, a teraz wiem, że musi być wyrównany do końca. Teraz działa.

To jak ja zorientowaliśmy się:

tail -f /var/log/syslog 
Jun 26 10:54:59 saturn7 init: app_name main process (3521) terminated with status 127 

I okazało się, że stan 127 jest w zasadzie poleceń, które nie zostało znalezione. Wiem więc, że problem tkwił w pliku skryptu.

Ale nie jestem pewien, dlaczego bash ./script.sh zadziała i nie powie mi, że coś jest nie tak? Muszę przeczytać o skryptach schell ..

+0

Uruchamiam wszystkie moje skrypty typu "upstart" za pomocą komendy 'exec>/var/log/$ {UPSTART_JOB} .log 2> & 1', a następnie' set -x' - wyprowadza każdą linię wykonaną do/var/log/[upstart-job] .log i masz jasne pojęcie, dlaczego i kiedy coś zawodzi. Zostałem złapany przez setuida nieobsługiwanego we wcześniejszej wersji upstart – jmurphyau