Alternatywa dla Daemontools (djbtools) do nadzorowania procesów unixowych?

Użyłem Daemontools, aby zapewnić prosty i niezawodny sposób nadzorowania usług Unix na moich serwerach. Działa dobrze, ale wymaga innego sposobu myślenia ( The DJB Way ), a niektóre typowe skargi to:

• Znaczniki czasu oparte na TAI64N
• Nie przechowuje skryptów w /etc/init.d (lub (/usr/local)/etc/rc.d)
• Nie zawsze działa ze skryptami takimi jak apachectl. Niektóre skrypty wymagają przepisania.

Pamiętam, że niektóre podobne demony „nadzorcy / stróża” pracowały około dwa lata temu, ale niektóre nadal były nieco szorstkie.

Jeśli przeszedłeś z Daemontools na coś innego, co wybrałeś i czy zadziałało to dobrze? Czy RedHat lub Ubuntu są domyślnie dostarczane z narzędziami nadzorującymi procesy?

Hrm, jeśli używasz Ubuntu, ich nowy proces inicjowania, upstart , obejmuje poziom nadzoru procesu. Może być używany do standardowego uruchamiania i zatrzymywania usług, skryptów inicjujących la SysV, a także może monitorować uruchomione aplikacje i odradzać je, jeśli umrą.

Za pomocą inittab możesz także wdrożyć proces ponownego uruchamiania biednego człowieka, w zależności od twoich potrzeb.

Jeśli przede wszystkim szukasz czegoś, co pozwoli ci mieć oko na proces, aby upewnić się, że zawsze działa, a następnie uruchom go ponownie, gdy nie jest, miałem wielkie szczęście z restartem . Niestety, jedynym źródłem, o którym wiem, jest pakiet Debian. Jest to jednak bardzo mała i prosta aplikacja, w zasadzie tylko jeden plik .c i .h z plikiem make. Kompilowanie go ze źródłowego archiwum Debiana na Red Hacie jest trywialne (nawet zrobiłem RPM tego przy poprzedniej pracy).

Ostatnią opcją, o której słyszałem, ale której nie użyłem, jest Inspektor . Wygląda na obiecujące narzędzie, ale restartowane działało w przeszłości dla mnie wystarczająco dobrze, na to, czego potrzebowałem, że jeszcze nie zadałem sobie z tym trudu.

+1 za runit. Więcej funkcji i elastyczność niż w daemontools, kompatybilna z istniejącymi argumentami i opcjami daemontools. Całkiem schludnie.

Ale jak wspomniałeś, wiele narzędzi ma własne pliki binarne kontrolne, apache2ctl, ejabberdctl, poundctl, collectd itp. I chociaż istnieją hacki, czasem lepiej po prostu trzymać się dostarczonych narzędzi, głównie wtedy, gdy nie jesteś pewien najczystszego możliwe wdrożenie. Zazwyczaj robię kompromis i większość usług działa pod nadzorem runita. Pozostałe można uruchamiać w trywialny sposób.

Cóż, jest runit . Nie mogę powiedzieć, jakie są różnice i podobieństwa do demonów, ale sądząc po stronie internetowej Bersteina, powiedziałbym, że istnieje wyraźny wpływ Bernsteina.

Fedora wydaje się być gotowa na przejście na systemd: http://0pointer.de/blog/projects/systemd.html

Jako alternatywa dla już wspomniano daemonizei daemontoolsnie jest demon znajomość pakietu libslack.

daemon jest dość konfigurowalny i dba o wszystkie żmudne rzeczy demona, takie jak automatyczne restartowanie, logowanie lub obsługa plików pidfile.

Jest nadzorca

Istnieje również narzędzie demona libslack napisane w C i dostępne na różne platformy (uniksowe).

Jest dość konfigurowalny i dba o wszystkie żmudne rzeczy demona, takie jak automatyczne restartowanie, logowanie lub obsługa plików pidfile.

Ubuntu zawiera Upstart - niewiele o nim wiem, ale wiem, że ma możliwości „nadzorcy”. Uruchomiona przez Apple jest kolejną opcją (ten artykuł w Wikipedii ma fajną sekcję „zobacz także”, która zawiera także listę innych, w tym Upstart & RunIt).

Wszystkie mają swoje dobre strony i swoją własną markę übersuck - Ilekroć ktoś pyta mnie o programy „nadzorujące proces” / „watchdog”, zawsze zadaję to samo pytanie: dlaczego potrzebujesz takiego?

Nie ma w tym celu żadnych popularnych / konsensusowych narzędzi, ponieważ każdy, kto pójdzie tą drogą, zdaje sobie sprawę, że to ślepa uliczka. Jeśli długo działające procesy zawodzą zbyt często, aby prosty monitoring był wystarczająco dobry, przestań ich używać i przenieś swój kod do czegoś, co będzie bardziej zależało od zdarzeń.

edycja: jak Chris wskazuje poniżej, czasami jesteś całkowicie opanowany, w takim przypadku zadanie cron * / 1, które szuka procesu / pliku pid, uruchamia start / restart, jeśli go brakuje, i wysyła wyniki do wiadomości e-mail do odpowiedzialnego programista / menedżer produktu to twoja awaryjna pozycja.