Przełożony nie ładuje nowych plików konfiguracyjnych

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?

Miałem ten sam problem, a

sudo service supervisord reload

zrobiłem lewę, choć nie wiem, czy to jest odpowiedź na twoje pytanie.

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

supervisorctl reread
supervisorctl update

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.

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 rereadpowodując skanowanie plików konfiguracyjnych pod kątem wszelkich zmian:

root@debian:~# supervisorctl reread
gunicorn: changed

Następnie po prostu załaduj ponownie tę aplikację:

root@debian:~# supervisorctl restart gunicorn
gunicorn: stopped
gunicorn: started

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:

$ sudo supervisorctl help restart
restart <name>          Restart a process
restart <gname>:*       Restart all processes in a group
restart <name> <name>   Restart multiple processes or groups
restart all             Restart all processes

W szczególności chcesz użyć składni:

sudo supervisorctl restart myapp_live:*

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.

Miałem podobny problem ( myapp_live: ERROR (no such process)) i to dlatego, że moja definicja procesu była

[program: myapp_live]

kiedy powinno być

[program:myapp_live]

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

Uważam, że to rozwiązanie jest najwygodniejsze:

EDYCJA: przed wykonaniem tej czynności sprawdź ścieżkę swojego opiekuna, which supervisorctlaby 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):

myappuser  ALL=(ALL) NOPASSWD: /usr/bin/supervisorctl restart myapp

A potem po prostu:

sudo supervisorctl restart myapp

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

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.

Oto lista kontrolna:

1. Nowy plik konfiguracyjny powinien mieć nazwę zgodną ze wzorcem dołączania skonfigurowanym w /etc/supervisord.conf:

   [include]
   files=supervisord.d/*.ini
   

   Jak widzimy w moim przypadku, spam.ini zostanie dołączony, ale spam.conf nie.

2. 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 rereadpozostawi ci ten beznadziejny komunikat o błędzie jako kara:

   No config updates to processes
   

3. Jeśli plik zostanie wykryty, supervisorctl rereadpowinien powiedzieć coś takiego:

   spam: available
   

4. Następnie supervisorctl update spamnależy go uruchomić i sprawić, by pojawił się w supervisorctl status.

Odkryłem, że skrypty init.d są zawodne w różnych wersjach Ubuntu / Debian. Sposób na zrobienie tego jest następujący:

sudo supervisorctl reload

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.

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.