Alternative zu Daemontools (djbtools) zur Überwachung von Unix-Prozessen?

Ich habe Daemontools verwendet , um eine einfache und zuverlässige Möglichkeit zur Überwachung von Unix-Diensten auf meinen Servern bereitzustellen. Es funktioniert gut, aber es erfordert eine andere Denkweise ( The DJB Way ) und einige häufige Beschwerden sind:

• TAI64N- basierte Zeitstempel
• Speichert keine Skripte unter /etc/init.d (oder (/usr/local)/etc/rc.d)
• Funktioniert nicht immer mit Skripten wie apachectl. Einige Skripte müssen neu geschrieben werden.

Ich erinnere mich, dass einige ähnliche "Supervisor / Watchdog" -Dämonen vor ungefähr zwei Jahren in Arbeit waren, aber einige waren noch ein wenig rau an den Rändern.

Wenn Sie von Daemontools zu etwas anderem gewechselt sind, was haben Sie gewählt und hat es für Sie gut funktioniert? Wird RedHat oder Ubuntu standardmäßig mit Dienstprogrammen zur Prozessüberwachung geliefert?

Hrm, wenn du Ubuntu verwendest, beinhaltet ihr neuer Init-Prozess, upstart , eine Ebene der Prozessüberwachung. Es kann für das standardmäßige Starten und Beenden von Diensten sowie für SysV-Init-Skripten verwendet werden. Außerdem kann es laufende Anwendungen überwachen und sie neu erstellen, wenn sie abstürzen.

Sie können auch einen Neustarter für den Prozess eines armen Mannes über inittab implementieren, je nachdem, welche Anforderungen Sie haben.

Wenn Sie in erster Linie nach etwas suchen, um einen Prozess im Auge zu behalten, um sicherzustellen, dass er immer ausgeführt wird, und um ihn dann neu zu starten, wenn dies nicht der Fall ist, hatte ich großes Glück mit restartd . Leider ist die einzige mir bekannte Quelle das Debian-Paket. Es ist jedoch eine sehr kleine und einfache Anwendung, im Grunde nur eine einzelne C- und H-Datei mit einer Make-Datei. Es ist trivial, es aus dem Debian-Quell-Tarball auf Red Hat zu kompilieren (ich habe bei meinem vorherigen Job sogar eine RPM daraus gemacht).

Eine letzte Option, von der ich gehört habe, die aber nicht verwendet wird, ist Supervisor . Es sieht aus wie ein vielversprechendes Tool, aber restartd hat in der Vergangenheit für mich gut genug funktioniert, für das, was ich brauchte, dass ich mich noch nicht darum gekümmert habe, damit zu spielen.

+1 für Runit. Mehr Funktionen und flexibler als daemontools, kompatibel mit vorhandenen daemontools-Argumenten und -Optionen. Ziemlich ordentlich.

Wie Sie bereits erwähnt haben viele Tools ihre eigenen Steuerungs-Binärdateien, apache2ctl, ejabberdctl, poundctl, collectd usw. Und obwohl es Hacks gibt, ist es manchmal besser, sich an die mitgelieferten Tools zu halten, vor allem, wenn Sie sich nicht sicher sind, ob sie die saubersten sind mögliche Umsetzung. Ich mache normalerweise einen Kompromiss und lasse die meisten Dienste unter der Aufsicht von runit ausführen. Und den anderen kann erlaubt werden, auf die triviale Art und Weise zu rennen.

Nun, es gibt Runit . Ich kann Ihnen nicht sagen, was die Unterschiede und Ähnlichkeiten mit daemontools sind, aber nach der Berstein-esque-Website würde ich sagen, dass es einen bestimmten Bernstein-Einfluss gibt.

Fedora scheint bereit zu sein, auf systemd umzusteigen : http://0pointer.de/blog/projects/systemd.html

Alternativ zu dem bereits erwähnten daemonizeund daemontoolsgibt es den Daemon- Befehl des libslack-Pakets.

daemon ist recht konfigurierbar und kümmert sich um alle langwierigen Daemon-Dinge wie automatischen Neustart, Protokollierung oder Pidfile-Behandlung.

Es gibt Supervisor

Es gibt auch das Daemon- Tool von libslack , das in C geschrieben und für verschiedene (Unix-) Plattformen verfügbar ist.

Es ist ziemlich konfigurierbar und kümmert sich um alle mühsamen Daemon-Dinge wie automatischen Neustart, Protokollierung oder Pidfile-Behandlung.

Ubuntu kommt mit Upstart - ich weiß nicht viel darüber, aber ich weiß, dass es "Supervisor" -Funktionen hat. Apples launchd ist eine weitere Option (dieser Wikipedia-Artikel hat einen schönen "see also" -Abschnitt, in dem auch einige andere aufgelistet sind, einschließlich Upstart & RunIt).

Alle haben ihre guten Seiten und eine eigene Marke von Übersuck - Immer wenn mich jemand nach "Process Supervisor" / "Watchdog" -Programmen fragt, stelle ich mir immer die gleiche Frage: Warum brauchen Sie eines?

Es gibt keine populären / Community-Consensus-Tools dafür, weil jeder, der diesen Weg einschlägt, erkennt, dass es eine Sackgasse ist. Wenn Ihre lang andauernden Prozesse zu oft fehlschlagen, um eine einfache Überwachung zu ermöglichen, beenden Sie die Verwendung und verschieben Sie Ihren Code in einen ereignisgesteuerteren Bereich.

edit: wie Chris weiter unten ausführt, sind Sie manchmal in die Enge getrieben. In diesem Fall führt ein * / 1-Cron-Job, der nach dem Prozess / der PID-Datei sucht, einen Start / Neustart durch, falls dieser fehlt, und gibt die Ergebnisse in einer E-Mail an den Verantwortlichen aus Entwickler / Produktmanager ist Ihre Ersatzposition.