Alternativa a Daemontools (djbtools) per supervisionare i processi unix?

Ho usato Daemontools per fornire un modo semplice e affidabile per supervisionare i servizi Unix sui miei server. Funziona bene, ma richiede un diverso modo di pensare ( The DJB Way ) e alcune lamentele comuni sono:

• Timestamp basati su TAI64N
• Non memorizza gli script in /etc/init.d (o (/usr/local)/etc/rc.d)
• Non funziona sempre con script come apachectl. Alcuni script devono essere riscritti.

Ricordo che alcuni demoni simili di "supervisore / cane da guardia" erano in lavorazione circa due anni fa, ma alcuni erano ancora un po 'agitati attorno ai bordi.

Se sei passato da Daemontools a qualcos'altro, cosa hai scelto e ha funzionato bene per te? RedHat o Ubuntu sono dotati di utilità di supervisore di processo per impostazione predefinita?

Hrm, se si sta utilizzando Ubuntu, il loro nuovo processo init, upstart , include un livello di supervisione di processo. Può essere utilizzato per l'avvio e l'arresto standard dei servizi, come script SysV init, e può anche monitorare le applicazioni in esecuzione e rigenerarle se muoiono.

Puoi anche implementare il riavvio del processo di un uomo povero tramite inittab, a seconda delle tue esigenze.

Se stai principalmente cercando qualcosa da tenere d'occhio su un processo, per assicurarti che sia sempre in esecuzione e quindi riavvialo quando non lo è, ho avuto molta fortuna con restartd . Sfortunatamente, l'unica fonte di ciò che conosco è il pacchetto Debian. Tuttavia, è un'applicazione molto piccola e semplice, praticamente solo un singolo file .c e .h, con un file make. Compilarlo dal tarball dei sorgenti Debian su Red Hat è banale (nel mio precedente lavoro ne ho persino realizzato un RPM).

Un'ultima opzione di cui ho sentito parlare, ma non utilizzata, è Supervisore . Sembra uno strumento promettente, ma riavvio ha funzionato abbastanza bene per me in passato, per quello di cui avevo bisogno, che non mi sono ancora preso la briga di giocarci.

+1 per runit. Più funzionalità e flessibilità rispetto ai daemontools, compatibile con gli argomenti e le opzioni esistenti di daemontools. Piuttosto pulito.

Ma come hai detto, molti strumenti vengono forniti con i propri binari di controllo, apache2ctl, ejabberdctl, poundctl, collectd, ecc. E sebbene esistano degli hack, a volte è meglio attenersi agli strumenti forniti, soprattutto quando non si è sicuri del più pulito possibile implementazione. Di solito faccio un compromesso e la maggior parte dei servizi viene eseguita sotto la supervisione di runit. E gli altri possono essere autorizzati a correre usando il modo banale.

Bene, c'è runit . Non posso dirvi quali sono le sue differenze e somiglianze con i demonoli, ma a giudicare dal sito web di Berstein, direi che c'è una chiara influenza di Bernstein.

Fedora sembra pronta a passare a systemd: http://0pointer.de/blog/projects/systemd.html

In alternativa al già citato daemonizee daemontools, c'è il comando daemon del pacchetto libslack.

daemon è abbastanza configurabile e si preoccupa di tutte le noiose cose del demone come il riavvio automatico, la registrazione o la gestione dei file pid.

C'è supervisord

C'è anche lo strumento demone di libslack che è scritto in C e disponibile per varie piattaforme (Unix).

È abbastanza configurabile e si preoccupa di tutte le noiose cose del demone come il riavvio automatico, la registrazione o la gestione dei file pid.

Ubuntu viene fornito con Upstart - non ne so molto ma so che ha capacità di "supervisore". Il lancio di Apple è un'altra opzione (l'articolo di Wikipedia ha una bella sezione "vedi anche" che elenca anche molti altri, tra cui Upstart e RunIt).

Tutti hanno i loro punti positivi e il loro marchio speciale di übersuck - Ogni volta che qualcuno mi chiede dei programmi "supervisore di processo" / "cane da guardia", faccio sempre la stessa domanda: perché ne hai bisogno?

Non ci sono strumenti popolari / di consenso della comunità per questo perché tutti coloro che percorrono questa strada si rendono conto che è un vicolo cieco. Se i tuoi processi di lunga durata falliscono troppo spesso perché il monitoraggio semplice sia abbastanza buono, smetti di usarli e sposta il codice all'interno di qualcosa che sarà più guidato dagli eventi.

modifica: come Chris sottolinea di seguito a volte sei completamente messo alle strette, nel qual caso un cron job * / 1 che cerca il processo / pidfile, esegue un avvio / riavvio se mancante e restituisce i risultati in un'e-mail al responsabile sviluppatore / product manager è la posizione di fallback.