Re: systemd e pid

[Pol Hallen]

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

[Federico Di Gregorio]

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

Re: Glusterfs mount boot

[Giuseppe Sacco]

Il giorno mar, 11/10/2016 alle 14.32 +0200, Luca ha scritto:
> Salve, 
> 
> ho il seguente problema nel montare il filesystem glusterfs al boot
> del server.
> Se faccio il mount manuale tutto funziona, mentre al boot no.
[...]

il mount dei file system in fstab avviene tra le prime cose, e
probabilmente il tuo file system richiede che il cluster sia già attivo
mentre in quel momento non lo è ancora.

Puoi avere maggiori dettagli con il comando «systemctl status --full
db.mount». Così magari vedi un messaggio d'errore più chiaro.

In ogni caso, pare che il problema sia conosciuto:
https://bugzilla.redhat.com/show_bug.cgi?id=1317559

E qui c'è una bella soluzione usando l'automount di systemd:
http://codingberg.com/linux/systemd_when_to_use_netdev_mount_option

Ciao,
Giuseppe

I'd like to add you to my learning network on Edmodo

[Alberto Saba]

Title: Edmodo












 





 











 








Hi debian-italian,
   
 
  
 

I'd like to add you to my global education network on Edmodo.



   
 

- Alberto Saba
   
 

 

  
  

  
Confirm that you know Alberto Saba
  

  







 








 







Terms of Service |
Privacy Policy |
  	Unsubscribe |
Support




 




Edmodo, Inc. | 1200 Park Place, Suite 400 | San Mateo, California 94403  







 

Re: Glusterfs mount boot

[Luca]

Al momento ho risolto utilizzando uno script per montare il filesystem
impostandolo in crontab di root:

@reboot sleep 60 && /root/script/mountgluster.sh

All'interno dello script verifico che il peer sia raggiungibile che il
servizio glusterfs sia attivo prima di procedere al mount.

Grazie a tutti per i consigli.

Luca.

Il giorno 11 ottobre 2016 16:07, emmanuel segura  ha
scritto:

> Ciao,
>
> Da un punto di vista logico, se fai riavvio di un nodo di un cluster,
> prima che il nodo vada giu, il nodo del cluster comunica a gli altri
> nodi, dicendo, sto andato giu, quindi un grateful shutdown, a questo
> punto, gli altri nodi rimuovono il nodo dalla loro lista dei nodi
> activi e lo mettono in stato dead.
>
> Quando il nodo parte e deve comunicare a gli altri che e tornato su,
> questo sarebbe il processo di join di un nodo a un cluster.
>
> Quindi, non e detto che quando viene eseguito il mount, il nodo faccia
> parte del cluster.
>
>
> Il 11 ottobre 2016 15:50, Luca  ha scritto:
> > Su rc.local avevo già provato, ma non funziona.
> >
> > Per cluster non ancora attivo cosa intendi? L'altro server è attivo, e
> > glusterfs è stato inizializzato in precedenza. Il problema si pone solo
> al
> > reboot.
> >
> > Luca.
> >
> > Il giorno 11 ottobre 2016 15:45, Luca De Andreis  ha
> scritto:
> >>
> >> Il 11 ottobre 2016 15:13:50 CEST, Walter Valenti <
> waltervale...@yahoo.it>
> >> ha scritto:
> >> >
> >> >
> >> >>
> >> >>ho il seguente problema nel montare il filesystem glusterfs al boot
> >> >del server.
> >> >>Se faccio il mount manuale tutto funziona, mentre al boot no.
> >> >>
> >> >>
> >> >>root@ciotola:~# systemctl status db.mount
> >> >>● db.mount - /db
> >> >>   Loaded: loaded (/etc/fstab)
> >> >>   Active: failed (Result: exit-code) since Tue 2016-10-11 14:25:35
> >> >CEST; 1min 34s ago
> >> >>Where: /db
> >> >> What: 127.0.0.1:/db_shared
> >> >> Docs: man:fstab(5)
> >> >>   man:systemd-fstab-generator(8)
> >> >>  Process: 380 ExecMount=/bin/mount -n 127.0.0.1:/db_shared /db -t
> >> >glusterfs -o defaults,_netdev (code=exited, status=1/FAILURE)
> >> >>
> >> >>
> >> >>Oct 11 14:25:35 ciotola mount[380]: extra arguments at end (ignored)
> >> >>Oct 11 14:25:35 ciotola mount[380]: Mount failed. Please check the log
> >> >file for more details.
> >> >>Oct 11 14:25:35 ciotola systemd[1]: db.mount mount process exited,
> >> >code=exited status=1
> >> >>Oct 11 14:25:35 ciotola systemd[1]: Unit db.mount entered failed
> >> >state.
> >> >>
> >> >>
> >> >>/etc/fstab:
> >> >>
> >> >>
> >> >>127.0.0.1:/db_shared/dbglusterfs defaults,_netdev
> >> > 0  0
> >> >>
> >> >
> >> >
> >> >
> >> >Non ho esperienze con glusterfs, ma a prima vista mi da l'idea che al
> >> >boot, quando
> >> >cerca di fare il mount gli manca qualcosa che non si è ancora avviato.
> >> >Prova a fare il mount al boot da rc.local anziché come servizio systemd
> >> >e vedi se te lo monta correttamente.
> >> >
> >> >
> >> >Walter
> >>
> >> Giusterfs è un file system clusterizzato e come tale richiede che tutta
> >> l'infrastruttura del cluster sia attiva ed il nodo quorato.
> >> Non è che è solo un problema di cluster non (ancora) attivo? Spesso non
> è
> >> proprio immediato, specie "agganciare" lo stato quorato non è
> rapidissimo e
> >> se tu tenti di fare un mount prima...
> >>
> >> Luca
> >>
> >
>
>
>
> --
>   .~.
>   /V\
>  //  \\
> /(   )\
> ^`~'^
>