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

68

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?

grucha
źródło
Drapałem się po głowie z tym samym problemem; moje pliki konfiguracyjne nie były ładowane podczas uruchamiania rereadlub update. Okazało się, że uratował moje pliki konfiguracyjne, jak foo.conf.pyzamiast foo.conftak nie zostałyby zidentyfikowane.
Timmy O'Mahony,

Odpowiedzi:

31

Miałem ten sam problem, a

sudo service supervisord reload

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

Hixi
źródło
2
Zatrzymałem się, a potem jakiś czas temu zacząłem nadzorować i zadziałało. Nie wiem, czy przeładowanie zadziałałoby (jak zrestartowało się serce), ale chyba tak
grucha
Ja też to zrobiłem i zadziałało. Zastanawiam się, dlaczego /etc/init.d/supervisor restartnie działa, gdy ręczne zatrzymanie i uruchomienie jest zrobione.
Kirill
1
Pracowałem dla mnie, chociaż usługa nie działała, więc po prostu pobiegłem, ps aux | grep supervisora potemsudo kill -HUP pid
Wayne Werner,
2
Jest to niebezpieczne, ponieważ spowoduje ponowne uruchomienie całego demona nadzorcy.
Mark Theunissen,
7
ponowne przeczytanie supervisorctl może to naprawić również bez ponownego uruchamiania usługi.
Jonathan Liuti
199

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
Mark Theunissen
źródło
13
To powinna być poprawna odpowiedź. Sam „przełożony ponownie przeczytał” nie wystarczy.
Miebster,
3
+1 To jest lepsza odpowiedź, ponieważ nie opiera się na menedżerach procesów.
tidwall
8
Sam „supervisorctl reread” nie wystarczy, ale czy „aktualizacja supervisorctl” nie wystarczy? Zgodnie z dokumentacją „aktualizacja” dokonuje ponownego odczytu, po którym następuje restart wszystkich programów, których konfiguracja została zmodyfikowana przez ponowne czytanie.
BlueBomber,
To działa dla mnie. Zrobiłem restart później.
user1012513
15

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.

nym
źródło
1
Zmarnowałem godzinę na ten sam problem - nie mogę uwierzyć, że to było takie proste.
Zane Hooper
1
Dziękujemy za wpisanie tej odpowiedzi. Przez całe życie nie mogłem tego rozgryźć.
Phillip Martin
14

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
Burhan Khalid
źródło
Jest to najlepsze rozwiązanie, jeśli chcesz tylko odczytać zmieniony / nowy plik konfiguracyjny i pozostawić pozostałe procesy bez zmian. Supervisorctl pokaże, że nowa aplikacja jest avail. Dodaj go do (ponownie) uruchamialnych procesów poprzez wydanie supervisorctl update. Zobacz także odpowiedź Marka: serverfault.com/a/479754/125887
Sjaak Trekhaak,
4
To mi nie wystarczało. supervisorctl updatebyło konieczne.
Jarosław Nikitenko
5

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.

pikomancer
źródło
4

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

Conrad.Dean
źródło
To samo tutaj! Zostawiłem to jako [program]jedyne, podążając za dokumentami, ale dzięki [program:redis]temu działało to dla mnie. Rzeczy czasem stają się dziwne!
ankush981
2

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

pielgrzym
źródło
2

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.

Sebastien Estienne
źródło
2

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.

użytkownik2394284
źródło
1

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
mafroza
źródło
To nie jest właściwy sposób, aby to zrobić, chociaż zadziała w wielu okolicznościach. @ burhan-khalid odpowiedź jest poprawna i zawiera wyjaśnienie.
glarrain
1

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.

Leo Pepe
źródło
0

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.

Aidas
źródło
To był również mój problem, prawdopodobnie wystąpi na wszystkich instalacjach Centos 6.5 lub mniejszych.
bearrito