Upewnij się, że proces jest zawsze uruchomiony


23

Zacząłem hostować strony jakiś czas temu, używając Cherokee. W przypadku źródeł zewnętrznych (FastCGI itp.) Ma opcję uruchomienia procesu, jeśli nie może znaleźć uruchomionego na wyznaczonym gnieździe lub porcie. Jest to świetne, ponieważ oznacza to, że jeśli PHP lub strona Django przewróci się (jak to czasami robią), automatycznie uruchomi się ponownie.

Na nowym serwerze używającym PHP-FPM nie mogłem używać Cherokee (ma błąd w PHP), więc przeniosłem się do NGINX. Bardzo podoba mi się NGINX (ze względu na styl konfiguracji), ale mam poważne problemy z procesami, które się przewracają i nigdy się nie odradzają. PHP robi to czasami, ale strony Django stanowią większy problem. Stworzyłem dla nich skrypty inicjujące, które uruchamiają się przy starcie systemu, ale to nie pomaga mi, jeśli konfigurują się między restartami.

Chyba szukam serwera proxy FastCGI. Coś, co, podobnie jak Cherokee, wie, jakie procesy powinny działać na których gniazdach / portach i odradza je na żądanie. Czy coś takiego istnieje? Czy jest jakiś sposób na wbudowanie tego w NGINX (dla ułatwienia konfiguracji)?

Odpowiedzi:


13

Co powiesz na Daemontools, a konkretnie narzędzie nadzoru

nadzoruje monitoruje usługę. Uruchamia usługę i uruchamia ją ponownie, jeśli umrze. Utworzenie nowej usługi jest łatwe: wszystkie potrzeby nadzorcze to katalog ze skryptem uruchamiającym, który uruchamia usługę.


+1 dla Daemontools. Często jednak nie można wrzucić do niego skryptu podobnego /etc/init.d/apachectldo tego. Często trzeba przepisać własny prosty skrypt startowy, aby go użyć exec. Chociaż chciałbym zobaczyć więcej przykładów z użyciem
Daemontools

daemontools ma kolejne wcielenie jako runit. Nie jest już tak ważne, że daemontools jest własnością publiczną, ale starsza dystrybucja może mieć tylko runit.
camh


5

Popieram tę daemontoolssugestię, ale jeśli nie podoba ci się sposób działania oprogramowania DJB (z jakiegokolwiek powodu), jest też supervisord.

Jakiś czas temu konfigurowałem obraz FreeBSD, który kiedyś służył supervisorddo zarządzania nginxi do gunicornktórego hostowałem kilka prostych aplikacji WSGI, a cały proces był dość prosty.

Jeśli robisz to dla Django, Gunicorn ułatwia wdrażanie aplikacji Django, btw. Zobacz ten post na blogu, aby uzyskać więcej informacji.


4

Inną opcją może być użycie monitora , którego zazwyczaj używam.


3

Czy zastanawiałeś się god?

Bóg jest łatwym do skonfigurowania, łatwym do rozszerzenia ramem monitorowania napisanym w Rubim.

Utrzymywanie procesów i zadań serwera powinno być prostą częścią procesu wdrażania. Bóg chce być najprostszą i najpotężniejszą dostępną aplikacją do monitorowania.

Używam go, aby upewnić się, że jeśli instancje Rails / nginx się przewrócą, zostaną przywrócone i chociaż nie widzę wbudowanej obsługi sprawdzania, czy używa właściwego portu, czy nie, ale jeśli problem polega na tym, że proces się nie powiedzie lub już nie działa, nie możesz się pomylić god.



0

Hackish rozwiązaniem byłoby okresowe uruchamianie skryptu (poprzez cron), który wykrywa, jeśli proces się nie powiedzie, i w tym przypadku uruchom go ponownie.


0

Istnieją różne sposoby ponownego uruchomienia uszkodzonego demona, zwykle zaleca się „odradzanie inittab”, ale z pewnym ograniczeniem, jeśli maszyna jest naprawdę przykręcona.

Demon watchdog może również monitorować proces za pomocą pliku PID. Należy to jednak traktować jedynie jako dodatkową linię obrony w celu ponownego uruchomienia komputera, który jest zbyt chory, aby działać poprawnie (np. Z pamięci, zbombardowanego wideł itp.), A nie jako podstawowy sposób monitorowania lub restartowania demona.

Wreszcie możesz rozważyć monitorowanie złożonych systemów za pomocą nagios, aby zapewnić administratorowi (administratorom) globalny widok. Może uruchamiać wtyczki, aby sondować działanie demona na zewnątrz, co jest bardziej kompletnym testem jego działania, niż że po prostu działa PID.


-1

Prosta odpowiedź - zacznij, gdzieś wypisz swój pid i za każdym razem x (sekundy, minuty, zakład) sprawdź, czy proces się zakończył.

Długa odpowiedź - wszystkie powyższe są dobrymi metodami. Ale nieco skomplikowane.

Pamiętaj również, że życie i odpowiadanie na prośby to różne rzeczy.


1
… I trzymajcie kciuki i miejcie nadzieję, że nic nie rysuje pliku PID, nie kasuje go, nie wykorzystuje go ponownie dla innego demona ani nie wskazuje go na inny niewinny i niezwiązany proces, który nie zareaguje dobrze na sprawdzenie za wstanie. ☺ Dlatego długa odpowiedź właściwego opiekuna demona, który uruchamia demony jako procesy potomne i monitoruje je za pomocą zwykłych mechanizmów systemu Unix / Linux, jest od dawna akceptowanym lepszym sposobem.
JdeBP
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.