Re: systemd e pid
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
Re: systemd e pid
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 -- Federico Di Gregorio federico.digrego...@dndg.it DNDG srl http://dndg.it And anyone who yells "fork" deserves to get one stuck in them. -- Dan Winship
systemd e pid
'sera a tutti :-) 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? grazie! Pol
