Mam problem z wdrożeniem aplikacji Django za pomocą Gunicorn i Supervisor. Chociaż mogę sprawić, że Gunicorn będzie służył mojej aplikacji (ustawiając odpowiednią PYTHONPATH i uruchamiając odpowiednią komendę, tą z konfiguracji superwizora), nie mogę sprawić, aby administrator ją uruchomił. Po prostu nie zobaczy mojej aplikacji. Nie wiem, jak się upewnić, czy plik konfiguracyjny jest w porządku.
Oto, co mówi supervisorctl:
# supervisorctl start myapp_live
myapp_live: ERROR (no such process)
Używam go na Ubuntu 10.04 z następującą konfiguracją:
Plik /home/myapp/live/deploy/supervisord_live.ini:
[program:myapp_live]
command=/usr/local/bin/gunicorn_django --log-file /home/myapp/logs/gunicorn_live.log --log-level info --workers 2 -t 120 -b 127.0.0.1:10000 -p deploy/gunicorn_live.pid webapp/settings_live.py
directory=/home/myapp/live
environment=PYTHONPATH='/home/myapp/live/eco/lib'
user=myapp
autostart=true
autorestart=true
W /etc/supervisor/supervisord.conf na końcu pliku znajduje się:
[include]
files = /etc/supervisor/conf.d/*.conf
a tutaj jest dowiązanie symboliczne do mojego pliku konfiguracyjnego:
# ls -la /etc/supervisor/conf.d
lrwxrwxrwx 1 root root 48 Dec 4 18:02 myapp-live.conf -> /home/myapp/live/deploy/supervisord_live.ini
wszystko wygląda dla mnie dobrze, ale przełożony ciągle mówi myapp_live: ERROR (no such process)
. Jakieś rozwiązanie tego?
źródło
reread
lubupdate
. Okazało się, że uratował moje pliki konfiguracyjne, jakfoo.conf.py
zamiastfoo.conf
tak nie zostałyby zidentyfikowane.Odpowiedzi:
Miałem ten sam problem, a
zrobiłem lewę, choć nie wiem, czy to jest odpowiedź na twoje pytanie.
źródło
/etc/init.d/supervisor restart
nie działa, gdy ręczne zatrzymanie i uruchomienie jest zrobione.ps aux | grep supervisor
a potemsudo kill -HUP pid
Prawidłowa odpowiedź jest taka, że przełożony wymaga ponownego przeczytania i aktualizacji po umieszczeniu nowego pliku konfiguracyjnego. Ponowne uruchomienie nie jest odpowiedzią, ponieważ wpłynie to na inne usługi. Próbować:
źródło
Upewnij się, że pliki conf Twojego przełożonego kończą się na .conf
Zajęło mi trochę czasu, żeby to rozgryźć. Mam nadzieję, że pomoże to następnej osobie.
źródło
Ponowne ładowanie procesu głównego przełożonego może działać, ale będzie miało niezamierzone skutki uboczne, jeśli przełożony monitoruje więcej niż jeden proces.
Prawidłowy sposób to zrobić,
supervisorctl reread
powodując skanowanie plików konfiguracyjnych pod kątem wszelkich zmian:Następnie po prostu załaduj ponownie tę aplikację:
źródło
avail
. Dodaj go do (ponownie) uruchamialnych procesów poprzez wydaniesupervisorctl update
. Zobacz także odpowiedź Marka: serverfault.com/a/479754/125887supervisorctl update
było konieczne.Ten problem napotkałem przy użyciu pakietu supervisora, wersja 3.0a8-1.1 z Ubuntu Server 12.10. Rozwiązałem problem, czytając wbudowaną pomoc:
W szczególności chcesz użyć składni:
Jak wynika z dokumentacji na stronie http://supervisord.org/configuration.html#programx-section - „Sekcja [program: x] w rzeczywistości reprezentuje„ jednorodną grupę procesów ”dla przełożonego (od 3.0).” Więc może problem pojawił się po raz pierwszy w wersji 3.0.
PS: Jestem nowy w przełożonym; Używam https://github.com/bdarnell/tornado-production-skeleton/blob/8ad055457646929c0e8f48aaf20d98f054b1787b/production/chat.supervisor jako przykład tego, jak powinna wyglądać minimalna konfiguracja.
źródło
Miałem podobny problem (
myapp_live: ERROR (no such process)
) i to dlatego, że moja definicja procesu byłakiedy powinno być
Chociaż nie odnosi się to do postawionego pytania, kierowało mnie wyszukiwanie, w którym szukam rozwiązania mojego problemu, więc mam nadzieję, że inni też go tu znajdą.
źródło
[program]
jedyne, podążając za dokumentami, ale dzięki[program:redis]
temu działało to dla mnie. Rzeczy czasem stają się dziwne!Uważam, że to rozwiązanie jest najwygodniejsze:
EDYCJA: przed wykonaniem tej czynności sprawdź ścieżkę swojego opiekuna,
which supervisorctl
aby upewnić się, że dodajesz właściwą ścieżkę do sudoers.Dodaj tę linię do pliku sudoers, używając
visudo
(gdzie:myappuser
- użytkownik, który musi zrestartować aplikację,myapp
- nazwa aplikacji):A potem po prostu:
Nie jesteś związany ze skryptami startowymi dystrybucji i dajesz dość wąskie uprawnienia użytkownikowi restartującemu aplikację gunicorn. Nie musisz też przejmować się pid. Polecenie nie prosi o podanie hasła, dlatego nadaje się do automatycznego wdrażania skryptów bash / fabric. Z drugiej strony - należy pamiętać, że jeśli supervisorctl jest podatny na błąd powodujący wykonanie kodu, złośliwy użytkownik może użyć tego uprawnienia sudo do uruchomienia kodu jako root (ale o ile wiem, taki błąd nie został wykryty dla administratora i odkrywanie takiej podatności to wielka rzecz).
źródło
Czytanie kodu supervisorctl.py tutaj: https://github.com/Supervisor/supervisor/blob/master/supervisor/supervisorctl.py
Możesz zobaczyć, że aktualizacja supervisorctl (funkcja do_update) wywołuje reloadConfig () dokładnie tak, jak robi to supervisorctl reread (funkcja do_reread).
Myślę więc, że ponowne odczytanie połączenia nie jest konieczne, jeśli wywołasz aktualizację po nim.
Z wyników git winy jest tak przynajmniej od lipca 2009 roku.
źródło
Oto lista kontrolna:
Nowy plik konfiguracyjny powinien mieć nazwę zgodną ze wzorcem dołączania skonfigurowanym w /etc/supervisord.conf:
Jak widzimy w moim przypadku, spam.ini zostanie dołączony, ale spam.conf nie.
Jeśli utworzyłeś nowy plik przez skopiowanie starego, upewnij się, że faktycznie zmieniłeś
[program:]
wiersz. Ponieważ jeśli jesteś tak głupi, jak posiadanie dwóch plików dla tego samego programu,supervisorctl reread
pozostawi ci ten beznadziejny komunikat o błędzie jako kara:Jeśli plik zostanie wykryty,
supervisorctl reread
powinien powiedzieć coś takiego:Następnie
supervisorctl update spam
należy go uruchomić i sprawić, by pojawił się wsupervisorctl status
.źródło
Odkryłem, że skrypty init.d są zawodne w różnych wersjach Ubuntu / Debian. Sposób na zrobienie tego jest następujący:
źródło
Uważaj na dowiązania symboliczne i dołączaj pliki do opiekuna. Pozwoliłoby to każdej osobie z uprawnieniami w na /home/myapp/live/deploy/supervisord_live.ini zmienić plik ini i uruchomić dowolny złośliwy kod. Te pliki ini powinny znajdować się w katalogu conf twojego przełożonego lub w dowolnym podkatalogu pod nim.
źródło
Zainstalowałem supervisor z instalacją yum, która zainstalowała supervisor wersji v2. *. Supervisor obsługuje zewnętrzne obejmuje tylko od wersji 3. Musiał zamiast tego użyć easy_install, aby zainstalować supervisor v3.
źródło