In generale un processo (demone) una volta lanciato deve funzionare, punto e basta. Può capitare però che per colpa di qualche bug non ancora risolto, il processo muoia e sia neccessario riavviarlo manualmente.

E' il caso di Spamassassin 3.3.2 con Perl 5.14.2 su Debian Wheezy, ogni tanto il processo spamd muore senza motivo. Nei file di log si trova:

spamd[4563]: prefork: adjust: 10 idle children more than 9 maximum idle children. Decreasing spamd children: 27150 killed.
spamd[4563]: spamd: handled cleanup of child pid [27150] due to SIGCHLD: interrupted, signal 2 (0002)
spamd[4563]: spamd: handled cleanup of child pid [27151] due to SIGCHLD: interrupted, signal 2 (0002)

e poi niente altro (il processo spamd padre è morto). Potrebbe trattarsi di un bug, secondo i seguenti post:

• https://bugzilla.redhat.com/show_bug.cgi?id=812359
• https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6745

Come workaround al problema si installa monit, che semplicemente monitora la presenza del demone spamd e se necessario lo riavvia.

Questo lo snippet di configurazione da salvare in /etc/monit/conf.d/spamd:

 check process spamd with pidfile /var/run/spamd.pid
   group spamd
   start program = "/etc/init.d/spamassassin start" 
   stop  program = "/etc/init.d/spamassassin stop"
   if 5 restarts within 5 cycles then timeout
   if cpu usage > 99% for 5 cycles then alert
   if mem usage > 99% for 5 cycles then alert
   depends on spamd_bin
   depends on spamd_rc

 check file spamd_bin with path /usr/sbin/spamd
   group spamd
   if failed checksum then unmonitor
   if failed permission 755 then unmonitor
   if failed uid root then unmonitor
   if failed gid root then unmonitor

 check file spamd_rc with path /etc/init.d/spamassassin
   group spamd
   if failed checksum then unmonitor
   if failed permission 755 then unmonitor
   if failed uid root then unmonitor
   if failed gid root then unmonitor

Attenzione: Monit esegue un ciclo di test ogni due minuti (impostazione predefinita Debian, vedi set daemon 120 in /etc/monit/monitrc). Quando deve riavviare un servizio attende fino a 30 secondi per lo stop e lo start dello stesso, è possibile modificare tale tempo con l'opzione with timeout. In base a questi parametri bisogna aggiustare il timeout (cioè quando scatta l'interruzione del monitoraggio) dopo un certo numero di restart avvenuti in un certo numero di cicli (if 5 restarts within 5 cycles then timeout). In caso contrario si ottiene

...
[CET Mar 28 16:53:40] info     : 'spamd' start: /etc/init.d/spamassassin
[CET Mar 28 16:54:11] error    : 'spamd' failed to start
[CET Mar 28 16:56:11] error    : 'spamd' process is not running
[CET Mar 28 16:56:11] info     : 'spamd' trying to restart
[CET Mar 28 16:56:11] info     : 'spamd' start: /etc/init.d/spamassassin
[CET Mar 28 16:56:43] error    : 'spamd' failed to start
[CET Mar 28 16:58:43] error    : 'spamd' service restarted 5 times within 5 cycles(s) - unmonitor

Ecco quindi una configurazione che insiste più a lungo per riavviare il servizio e che esegue una azione drastica (killall -9) se il restart fallisce per 4 volte:

   ...
   start program = "/etc/init.d/spamassassin start" 
   stop  program = "/etc/init.d/spamassassin stop" with timeout 60 seconds
   if 4 restarts within 4 cycles then exec "/usr/bin/killall -9 spamd"
   if 10 restarts within 10 cycles then timeout
   ...

Poi alcuni parametri sono stati aggiustati in /etc/monit/monitrc:

  set daemon 120            # check services at 2-minute intervals
  with start delay 240      # optional: delay the first check by 4-minutes (by 

  set mailserver localhost

  set alert support@texnet.it                    # receive all alerts

  set httpd port 2812 and
    use address 62.48.51.60  # only accept connection from localhost
    allow 62.48.51.60        # allow localhost to connect to the server and
    allow 62.48.51.8         # allow a remote host to connect to the server and
    allow admin:MySecret     # require user 'admin' with password 'monit'
    allow @monit             # allow users of group 'monit' to connect (rw)
    allow @users readonly    # allow users of group 'users' to connect readonly

Se un processo monitorato si blocca, viene tentato il suo riavvio. Potrebbe capitare che il processo non riesca a partire nei tempi previsti, ad esempio spamd che non ha rilasciato il socket:

spamd[8042]: spamd: could not create INET socket on 127.0.0.1:783: Address already in use

In tal caso il processo non viene più sottoposto a monitoraggio, neanche dopo un reboot. Per riattivare il monitoraggio:

monit monitor spamd