ciao, grazie per la spiegazione: molto utile e chiara :-)

il tutto nasce da monit (che monitora i daemon appunto tramite il loro PID file).

Indagherò

Pol

On 10/12/2016 07:07 PM, Federico Di Gregorio wrote:
On 11/10/16 20:30, Pol Hallen wrote:

premetto che non ho molta simpatia per systemd :-/

mi accorgo che sulla stable in /run/ non ci sono i PID di openvpn,
smartmontools e anche di mdadm ma sto ancora indagando... (mentre sulla
testing sono presenti)

siccome ho degli script che vanno a verificare questi PID, qualcuno mi
potrebbe dare una mano a capire perchè systemd non crei i PID file?

Fondamentalmente, perché non ne ha bisogno.

Spiegazione lunga: storicamente un demone in unix/linux si sgancia
dall'input/output eseguendo quello che si definisce un double-fork che,
tra le altre cose, rende il processo figlio senza genitore e quindi
responsabilità del processo di init. In questo modo, se dovesse morire,
è compito di init "ripulire" per non avere processi zombie nel sistema.
Per fare questo ci sono 2 modi: il demone esegue direttamente il
double-fork oppure si usa un qualche tipo di aiuto, come i
system-daemon-tools. Con questa procedura l'unico modo per l'utente di
mandare un segnale ad un processo è con il suo PID che in genere viene
scritto in /var/run. Ovviamente se il processo muore e nessuno cancella
il file da /var/run si crea una situazione inconsistente. Il demone non
viene rilanciato in automatico, perché init classico (sysv per
intenderci) non sa come fare.

systemd gestisce _direttamente_ i demoni facendoli partire senza
double-fork e mettendoli in un cgroup per tenerli sotto controllo. In
questo modo il processo di init (systemd) si accorge se uno dei figli
muore e può rilanciarlo o fare altro a seconda della configurazione. Il
PID serve solo più se un demone supporta solo il double-fork, nel qual
caso systemd deve essere informato del PID del demone per poterlo
gestire (ma nota che systemd NON crea mai il PID). Questo è MOLTO più
solido che non basarsi sui PID scritti in /var/run perché lo stato del
sistema è sempre coerente: se systemd ti dice che un demone è "running",
allora lo è, altrimenti nel caso non possa/voglia rilanciarlo, ti dice
con che stato è uscito.

Con systemd, per sapere se un processo sta girando puoi usare systemctl
e nel caso tu voglia mandargli un segnale, "systemctl kill"

federico



--
Pol

Rispondere a