Ricerca nel sito web

Come riavviare automaticamente i servizi non riusciti su Non-systemd

Sulle distribuzioni Linux basate su systemd, la gestione e il riavvio automatico dei servizi dopo un errore è relativamente semplice. Tuttavia, molti sistemi Linux più vecchi o minimali si basano su sistemi di init alternativi come SysVinit e Upstart, che richiedono approcci diversi per gestire e riavviare i servizi.

In questa guida, esploreremo come riavviare automaticamente un servizio non riuscito su sistemi non systemd utilizzando SysVinit e Upstart.

1. Riavvio automatico dei servizi con SysVinit

SysVinit è uno dei più vecchi sistemi di init, comunemente usato in distribuzioni come Debian e CentOS prima della transizione a systemd.

Passaggio 1: Installare e configurare monit

Monit è un'utilità leggera e open source che monitora i servizi e li riavvia automaticamente quando non funzionano.

# On Debian/Ubuntu
sudo apt update
sudo apt install monit

On CentOS/RHEL
sudo yum install monit

Passaggio 2: Configurare Monit per il monitoraggio di un servizio

Modificare il file di configurazione Monit:

sudo nano /etc/monit/monitrc

Aggiungere una definizione di servizio:

# Example: Monitor Apache service
check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/etc/init.d/apache2 start"
    stop program = "/etc/init.d/apache2 stop"
    if failed port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

Spiegazione della definizione di servizio di cui sopra:

  • check process apache2 – Definisce il servizio da monitorare.
  • start/stop program – Comandi per avviare e arrestare il servizio.
  • in caso di errore porta 80: si riavvia se la porta HTTP diventa irraggiungibile.

Successivamente, abilita, avvia e verifica lo stato di monit.

sudo systemctl enable monit
sudo systemctl start monit
sudo monit status

2. Riavvio automatico dei servizi con Upstart

Upstart era il sistema di init predefinito su Ubuntu prima di systemd, e utilizza i file di configurazione situati in /etc/init/ per definire la gestione dei servizi.

Passaggio 1: Creare un file di configurazione Upstart

Creare una configurazione Upstart personalizzata per il servizio.

sudo nano /etc/init/apache2.conf

Aggiungi il seguente contenuto.

# Apache service monitoring
description "Apache2 Service"
start on runlevel [2345]
stop on runlevel [!2345]

respawn
respawn limit 10 5

exec /usr/sbin/apache2ctl -D FOREGROUND

Spiegazione della configurazione di cui sopra:

  • respawn: riavvia automaticamente il servizio in caso di errore.
  • limite di rigenerazione 10 5 – Limita i riavvii a 10 tentativi entro 5 secondi per evitare riavvii eccessivi.

Successivamente, abilitare, avviare e gestire il servizio.

sudo start apache2
sudo stop apache2
sudo status apache2

Per abilitare automaticamente il servizio all'avvio.

sudo update-rc.d apache2 defaults

3. Utilizzo di Cron per riavviare manualmente i servizi

Se monit o Upstart non sono disponibili, un approccio di fallback consiste nell'utilizzare un cron job per controllare e riavviare periodicamente il servizio.

Creare uno script di shell.

sudo nano /usr/local/bin/check_apache.sh

Aggiungi il seguente contenuto.

#!/bin/bash
if ! pgrep -x "apache2" > /dev/null
then
    /etc/init.d/apache2 start
fi

Rendere eseguibile lo script.

sudo chmod +x /usr/local/bin/check_apache.sh

Aggiungere un cron job per eseguire lo script.

sudo crontab -e

Aggiungi la riga seguente per controllare il servizio ogni 5 minuti.

*/5 * * * * /usr/local/bin/check_apache.sh

Se siete interessati a impostare il riavvio automatico per altri sistemi di init, date un'occhiata a questi articoli:

  • Come impostare il riavvio automatico per i servizi non riusciti su OpenRC
  • Come trovare i servizi in esecuzione in Linux con i comandi systemd
Conclusione

Il riavvio automatico dei servizi guasti su sistemi non systemd richiede un po' più di configurazione manuale, ma strumenti come monit, Upstart o script cron possono gestire in modo efficiente i guasti del servizio e mantenere le applicazioni in esecuzione senza problemi.

Se stai ancora utilizzando un sistema non systemd, potrebbe valere la pena considerare un aggiornamento a una distribuzione basata su systemd per una gestione più semplice del servizio.