Ci spiace, ma questo articolo è disponibile soltanto in Inglese Americano.
Oct 202014
Article di Mikko Ohtamaa già pubblicato sul suo blog
Spesso si vuole automatizzare qualcosa usando scripting di shell. In un mondo perfetto il vostro script funziona senza problemi, senza stancarsi, senza errori, e ci si può sedere nella vostra scrivania e sorseggiare un caffè.
Poi entriamo nel mondo reale: La rete è scollegata. Il DNS va male. I vostri hook HTTP e download vanno in stallo. La comunicazione tra processi si blocca. Effettivamente questo significa che, anche se lo script viene eseguito correttamente dal punto di sistema operativo questo non finirà il suo lavoro prima che voi terminiate la vostra tazza di caffè.
Articolo di Stuart Burns pubblicato su Openlogic.com
Con il rilascio di Red Hat Enterprise Linux 7 e CentOS versione 7, ora è un buon momento per parlare di systemd, che sostituirà il classico System V (SysV) per tutti gli script di avvio e runlevel. Le distribuzioni basate su Red Hat-stanno migrando a systemd perché fornisce modi più efficienti di gestione dei servizi e tempi di avvio più rapidi. Con systemd ci sono meno file da modificare, e tutti i servizi sono compartimenti stagni separati gli uni dagli altri. Ciò significa che nel caso in cui si dovesse rovinare un file di configurazione, non si influirà automaticamente sugli altri servizi.
Systemd è il responsabile del sistema e dei servizi di default in Red Hat Fedora dal rilascio di Fedora 15, quindi è ampiamente testato sul campo. Esso fornisce una maggiore coerenza e capacità di risoluzione dei problemi SysV – per esempio, segnalerà se un servizio non è ripartito, è sospeso, o è in errore. Forse il più grande motivo per il passaggio a systemd è che consente a più servizi di partire, allo stesso tempo, in parallelo, rendendo i tempi di avvio della macchina più veloci di quanto lo sarebbero con un runlevel classico.