Breaking Monitor
come scrivere un Process Monitor in C
Saul Goodman: Come l'avete portato qui? Noi siamo come i tre moschettieri! "Tutti per uno e uno per tutti" Non ci serve un quarto moschettiere. Walter White: Saul, Mike conosce il suo lavoro e i distributori. È uno a posto. Saul Goodman: Uno a posto? Ha promesso di rompermi le gambe! E non mi dite che non parlava sul serio, perché quando fa lo sguardo da pesce morto parla sul serio! Walter White: Ha minacciato anche me e Jesse e chissà quante altre persone minaccia ogni giorno. È il suo mestiere. Andiamo, è fatto così.
Questa volta invece di citare un film citeremo una serie TV di alta qualità, tanto alta da farne un “film lunghissimo”. Breaking Bad è Cinema, e anche di quello buono. E cosa vuol dire Breaking Bad? Vuol dire “allontanarsi dalla retta via”, che è proprio quello che fanno, a volte, i processi di un Sistema Operativo: smettono di funzionare e creano problemi. E quale potrebbe essere la soluzione? Ma usare un Process Monitor, Elementare, mio caro Watson!
Allora, chiariamo subito di cosa stiamo parlando: vi sarà capitato sicuramente (a chi non è capitato? sono cose che succedono tutti i giorni!) di scrivere una applicazione che, a sua volta, lancia altre applicazioni, quindi siamo nel caso classico (già visto su questi schermi) di un processo che fa fork + exec (su Linux e sistemi POSIX), magari più volte. Normalmente il processo padre lavora in collegamento con i processi figli, e se qualche processo muore (il padre o i figli) potrebbero crearsi dei (notevoli) problemi di funzionamento. Normalmente la cosa si risolve a livello OS, per esempio usando una applicazione ad-hoc (una buona e molto usata è Monit) oppure ci si aiuta con le utility del sistema operativo, usando systemd o scrivendo degli shell script.
Ma questa è la soluzione che vi proporrebbe un sistemista, mentre noi siamo programmatori! (…beh, per esigenze di lavoro, molti sono entrambe le cose, incluso il sottoscritto, ma questa è un altra storia…). E il discorso è semplice: se abbiamo un mix di applicazioni slegate, che devono partire e lavorare insieme, allora si usa l’approccio sistemistico, ma se il progetto prevede già una applicazione master che avvia, con fork(), dei sotto-processi, la maniera più intelligente di monitorare è di farlo già a livello codice, senza scomodare il Sistema Operativo e/o applicazioni esterne.
E come si può scrivere un semplice ed efficiente Process Monitor in C? Lo vedremo tra poco! Allora, come sempre vi mostrerò del codice il più possibile semplice e chiaro, ma già preparato per essere usato in produzione (previa l’aggiunta di una gestione più completa degli errori). Non sarà un semplice demo ultra-semplificato, sarà una roba ben fatta (scusate la modestia) sviluppata a mo’ di libreria e che può essere facilmente integrata in qualsiasi progetto.
Il nostro Process Monitor, quindi, è una piccola libreria formata da due soli file, un header e una implementazione. L’ho chiamata con l’originalissimo nome di ProcMonit. Ma facciamo parlare il codice, partiamo dall’header ProcMonit.h:
#ifndef PROCMONIT_H_
#define PROCMONIT_H_
#include <stdbool.h>
#include <pthread.h>
#include <sys/types.h>
// struttura dati per ProcMonit
typedef struct {
// dati del processo figlio da monitorare
const char* file; // nome del file da eseguire
char* const* argv; // lista di argomenti del programma da eseguire
pid_t pid; // pid del processo figlio avviato
// dati del thread del monitor
pthread_t t_procmonit; // descrittore del thread
bool stop_t_procmonit; // flag per lo stop del thread
} ProcMonit;
// prototipi globali
void pm_init(ProcMonit *pm, const char* pm_file, char* const pm_argv[]);
void pm_start(ProcMonit *pm);
void pm_stop(ProcMonit *pm);
#endif // PROCMONIT_H_
La semplicità è disarmante e già lascia presagire come sarà l’implementazione: abbiamo una struttura dati che contiene tutti i (pochi) dati necessari al funzionamento (ben descritti nei commenti, come sempre) e solo tre funzioni (con nomi abbastanza espliciti): pm_init(), pm_start() e pm_stop(). Il meccanismo di Monitor che vogliamo implementare è il seguente:
- avere la possibilità di avviare n processi figli (usando n volte pm_init() e pm_start()).
- sorvegliare lo stato dei processi figli: se uno termina (per un errore interno, per un segnale esterno, ecc) bisogna riavviarlo automaticamente.
- terminare automaticamente i processi figli nel caso di terminazione del processo padre.
Ovviamente si possono prevedere varianti di questo funzionamento, ma vi assicuro che quello che si usa di solito (con Monit, ad esempio) segue lo schema citato. E come si implementa questo? Vediamolo, vai con ProcMonit.c!
#define _GNU_SOURCE
#include "ProcMonit.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/stat.h>
#include <sys/prctl.h>
// prototipi locali
static void *pm_thread(void *arg);
// pm_init - inizializza la struttura del monitor
void pm_init(ProcMonit *pm, const char *pm_file, char* const pm_argv[])
{
// set/reset dati del monitor
pm->file = pm_file; // nome del file da eseguire
pm->argv = pm_argv; // lista di argomenti del programma da eseguire
pm->pid = -1; // pid del processo figlio avviato
pm->t_procmonit = 0; // descrittore del thread
pm->stop_t_procmonit = false; // flag per lo stop del thread
}
// pm_start - avvia il monitor di un processo figlio
void pm_start(ProcMonit *pm)
{
// test se il thread non è già allocato
if (pm->t_procmonit == 0) {
// start del thread di procmonit
pm->stop_t_procmonit = false; // reset flag per stop thread
int error;
if ((error = pthread_create(&pm->t_procmonit, NULL, &pm_thread, pm)) != 0) {
// errore: lo mostro e azzero il descrittore del thread
printf("%s: non posso creare il thread (%s)\n", __func__, strerror(error));
pm->t_procmonit = 0;
}
}
}
// pm_stop - ferma il monitor di un processo figlio
void pm_stop(ProcMonit *pm)
{
// test se il thread è allocato
if (pm->t_procmonit) {
// uccide il processo figlio
kill(pm->pid, SIGKILL);
// stop e join del thread di procmonit
pm->stop_t_procmonit = true; // set flag per lo stop del thread
pthread_join(pm->t_procmonit, NULL);
pm->t_procmonit = 0; // reset del descrittore del thread
}
}
// pm_thread - funzione per il thread di procmonit
static void *pm_thread(void *arg)
{
// estraggo l'argomento con un cast
ProcMonit *pm = (ProcMonit *)arg;
// redirigo stdout e stderr su un file di log (questa parte è opzionale)
char log_fname[64];
snprintf(log_fname, sizeof(log_fname), "%s.log", pm->file);
int fd = open(log_fname, O_WRONLY | O_CREAT | O_TRUNC, DEFFILEMODE);
//dup2(fd, STDOUT_FILENO); // invia stdout al file fd (opzionale)
//dup2(fd, STDERR_FILENO); // invia stderr al file fd (opzionale)
close(fd); // posso chiudere fd visto che è già stato duplicato
// loop del thread
while (!pm->stop_t_procmonit) {
// fork del processo
pid_t parent_pid = getpid();
pm->pid = fork();
// test dei pid dei processi
char errmsg_buf[256]; // buffer per la strerror_r(): 256 è il size raccomandato
if (pm->pid == 0) {
// sono il figlio: con prctl() prenoto lo stop (via signal) se termina il padre
if (prctl(PR_SET_PDEATHSIG, SIGTERM) == -1) {
// errore nella prctl()
fprintf(stderr, "%s: sono il figlio (%d): errore prtctl(): %s\n",
pm->argv[1], getpid(),
strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
exit(EXIT_FAILURE);
}
// nel caso che il processo padre esca prima di chiamare la prctl()
if (getppid() != parent_pid) {
// errore nella prctl()
fprintf(stderr, "%s: sono il figlio (%d): errore prtctl()\n",
pm->argv[1], getpid());
exit(EXIT_FAILURE);
}
// continua l'esecuzione del figlio eseguendo un nuovo processo
fprintf(stderr, "%s: sono il figlio (%d): eseguo il nuovo processo: %s\n",
pm->argv[1], getpid(), pm->file);
execv(pm->file, pm->argv);
exit(EXIT_FAILURE); // exec non ritorna mai
}
else if (pm->pid > 0) {
// sono il padre: attendo l'uscita del figlio
fprintf(stderr, "%s: sono il padre (%d): "
"attendo la terminazione del figlio %s (%d)\n",
pm->argv[1], getpid(), pm->file, pm->pid);
int status;
if (waitpid(pm->pid, &status, 0) != pm->pid) {
// errore nella waitpid()
fprintf(stderr, "%s: sono il padre (%d): "
"errore waitpid() figlio %s (%d): %s\n",
pm->argv[1], getpid(), pm->file, pm->pid,
strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
}
else {
// processo terminato: mostro lo status
if (WIFEXITED(status))
fprintf(stderr, "%s: sono il padre (%d): "
"figlio %s (%d) uscito ((status=%d))\n",
pm->argv[1], getpid(), pm->file, pm->pid,
WEXITSTATUS(status));
else if (WIFSIGNALED(status))
fprintf(stderr, "%s: sono il padre (%d): "
"figlio %s (%d) ucciso dal segnale %d\n",
pm->argv[1], getpid(), pm->file, pm->pid,
WTERMSIG(status));
else if (WIFSTOPPED(status))
fprintf(stderr, "%s: sono il padre (%d): "
"figlio %s (%d) fermato dal segnale %d\n",
pm->argv[1], getpid(), pm->file, pm->pid,
WSTOPSIG(status));
else
fprintf(stderr, "%s: sono il padre (%d): "
"figlio %s (%d) terminato ((status=%d))\n",
pm->argv[1], getpid(), pm->file, pm->pid, status);
}
}
else {
// errore nella fork(): mostro errore e continuo
fprintf(stderr, "%s: processo %s: errore fork(): %s\n",
pm->argv[1], pm->file,
strerror_r(errno, errmsg_buf, sizeof(errmsg_buf)));
}
}
// il thread esce
pthread_exit(NULL);
}
Che ne dite? Come si nota il funzionamento si basa su un thread (in questo articolo c’è un bel mix esplosivo, processi e thread allo stesso tempo!) che si occupa di monitorare lo stato del processo figlio. Riepiloghiamo il funzionamento centrandoci sulle tre funzioni globali:
- pm_init(): inizializza la struttura dati del Monitor. Tra i dati possiamo evidenziare il filename che verrà eseguito dal processo figlio (con i relativi argomenti di esecuzione) e le variabili di supporto per gestire il thread di Monitor e il processo figlio.
- pm_start(): avvia il thread che si occupa di eseguire il processo figlio e di sorvegliarne la attività, per gestire gli eventuali restart. Qualcuno potrebbe (giustamente) commentare: “Ma la pm_init() e la pm_start() non potrebbero essere una unica funzione?” No, e la risposta si chiama pm_stop().
- pm_stop(): ferma il processo figlio e il thread di controllo. Dopo lo stop si può, se necessario, eseguire un nuovo start… “Ah, allora è per questo che abbiamo init e start in due fasi! La init si chiama una volta sola, mentre la start si può ri-chiamare dopo ogni stop!” Bravo, risposta esatta.
E adesso è il turno del cuore del Process Monitor, la funzione pm_thread() che è quella che viene eseguita dal thread di controllo (e non è esportata globalmente nel header, visto che viene usata solo internamente alla libreria). Il funzionamento è abbastanza semplice e ricalca, in una certa maniera, la struttura del file processes.c di alcuni recenti articoli: esegue fork() e divide il flusso in padre (che sorveglia) e figlio (che esegue con execv() un nuovo processo). E come avviene il monitoring? Il flusso padre resta in attesa dell’uscita del figlio all’interno di un loop pseudo-infinito: in questa maniera, se il figlio muore viene rieseguita la fork() e si ripete il ciclo indefinitamente, fino a quando non viene richiesto lo stop definitivo attraverso la funzione pm_stop(). Non male, no?
Nella funzione pm_thread() ci sono almeno tre trucchetti interessanti, che possiamo descrivere brevemente (per i dettagli leggere bene i commenti nel codice):
- Redirezione di stdout e stderr: visto che abbiamo più processi in esecuzione, con (vari ed eventuali) messaggi di errore, è una buona idea redirigere le scritture (su un file di log, come nell’esempio, oppure su /dev/null se vogliamo silenziare il tutto). Questa parte è opzionale (ma utile).
- Intercettazione dei segnali attraverso la funzione prctl(): serve per automatizzare la terminazione del processo figlio nel caso di uscita del processo padre (questa parte è veramente interessante, segnatevela).
- nel flusso padre, trattamento completo dello status di uscita del processo figlio: ho usato le apposite (e non molto conosciute) macro della wait(): WIFEXITED(), WEXITSTATUS(), WIFSIGNALED(), WTERMSIG(), WIFSTOPPED() e WSTOPSIG(): in questa maniera il controllo di eventuali errori è veramente ben fatto.
Cosa ci manca per terminare? Ma un semplicissimo esempio d’uso! Quindi vi propongo un caso veramente elementare, con un programma padre parent.c e un programma figlio child.c. Il processo padre in questo caso monitorizza solo un figlio, ma può monitorizzarne n a piacere semplicemente moltiplicando le chiamate di init, start e stop: ogni nuova pm_init() inizializza un nuovo processo da eseguire su cui possiamo eseguire le relative pm_start() e pm_stop(). Semplice e praticissimo. Vediamo il codice!
#include "ProcMonit.h"
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
// nome del processo figlio da avviare
#define CHILD_PROC "child"
// funzione main del processo padre
int main(int argc, char *argv[])
{
// init struttura procmonit
char* argv_pm[] = { (char*)CHILD_PROC, argv[0], (char*)NULL };
ProcMonit procmonit;
pm_init(&procmonit, CHILD_PROC, argv_pm);
// avvio il processo figlio usando procmonit
printf("%s: prenoto lo start del processo %s\n", argv[0], argv_pm[0]);
pm_start(&procmonit);
// main loop di test
for (int i = 0; i < 10; i++) {
printf("%s: loop interno di test: %d\n", argv[0], i);
sleep(3);
}
// fermo il processo figlio usando procmonit
printf("%s: prenoto lo stop del processo %s\n", argv[0], argv_pm[0]);
pm_stop(&procmonit);
// esco con Ok
return EXIT_SUCCESS;
}
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
// funzione main del processo figlio
int main(int argc, char *argv[])
{
// test loop
int i = 0;
for (;;) {
// test indice per chiusura forzata
if (i++ > 100) {
// chiusura forzata
printf("%s: il processo esce\n", argv[0]);
return EXIT_FAILURE;
}
// thread sleep (100 ms)
nanosleep((const struct timespec[]){{0, 100000000L}}, NULL);
}
// esco con Ok
return EXIT_SUCCESS;
}
Potete fare copia-incolla della libreria e degli esempi d’uso e compilare: con i tempi che ho impostato (e le scritte di log) vedrete il processo figlio che termina e si riavvia varie volte. E se provate, allo stesso tempo, a inviare un segnale di terminazione o uccisione al figlio potete mettere alla prova il riavvio automatico dopo un evento esterno. E se inviate un sigkill al padre vedrete che termina anche il figlio. Spero che vi piaccia (e se non vi piace me ne farò una ragione…). Ah, dimenticavo: i sorgenti di questo articolo li potete trovare anche nel mio repository GitHub.
Ciao, e al prossimo post!
