Guida a Systemd: introduzione e caratteristiche.

Systemd è un sistema ed un manager di servizi per Linux, compatibile con SysV e LSB init scripts. systemd fornisce potenti capacità di parallelizzazionne, usa attivazioni socket e D-Bus per avviare i servizi, offre inizializzazioni di demoni su richiesta, tiene traccia dei processi usando Linux cgroups, supporta lo snapshotting ed il ripristino dello stato del sistema, mantiene il mount e l'automount ed implementa un servizio logico di controllo. Può lavorare come rimpiazzo per sysvinit. Per maggiori informazioni sono disponibili i video http://linuxconfau.blip.tv/file/4696791/ o http://www.youtube.com/watch?v=TyMLi8QF6sw

Per gli amministratori di sistema
Gli amministratori di sistema possono visitare questa pagina per sapere come usare systemctl che sostituisce il vecchio flusso di lavoro in SysVinit. Da notare che i comandi service e chkconfig continueranno a funzionare come previsto anche in systemd.

Cos'é systemd?

Introduzione.

systemd inizializza e supervisiona l'intero sistema ed è basato sul concetto di units composto da nome/tipo stessi del file di configurazione da maneggiare (ad esempio, una unit avahi.service ha un file di configurazione con lo stesso nome ed è una unità incapsulata nel demone Avahi). Ci sono sette differenti tipi di units:

1. service: esistono tipologìe ovvie di unità: demoni che possono essere avviati, fermati, riavviati, ricaricati.
2. socket: questa unità contiene un socket nel file-system o su Internet. systemd attualmente supporta i socket AF_INET, AF_INET6, AF_UNIX di tipo stream, datagram e sequential packet. Può inoltre supportare i classici FIFO come transport. Ogni unità socket ha un servizio corrispondente, che viene inizializzato se la prima connessione avviene sul socket o FIFO (ad esempio nscd.socket inizializza nscd.service su una connessione in ingresso).
3. device: questa unità incapsula un dispositivo nell'albero dei dispositivi Linux. Se uno di loro viene contrassegnato attraverso una regola udev (udev rules), sarà esposto come unità dispositivo in systemd. Le proprietà impostate con udev possono essere usate come configurazione per impostare le dipendenze per le device units.
4. mount: questa unità incapsula un punto di montaggio (mount point) nel filesystem.
5. automount: questo tipo di unità incapsula un punto di automontaggio nel filesystem. Ogni unità automount corrisponde ad una unità mount, che viene avviata (montata) non appena la directory automount è accessibile.
6. target: questo tipo di unità per il logical grouping: invece di fare qualcosa autonomamente, semplicemente fa riferimento ad altre unità che possono essere controllate in gruppo. (ad esempio multi-user.target, che è un target che svolge praticamente il ruolo di run-level 5 nel classico sistema SysV; o bluetooth.target richiesto appena un dispositivo bluetooth è disponibile e che semplicemente avvìa di conseguenza i servizi relativi altrimenti non necessari: bluetoothd e obexd e simili).
7. snapshot: simile alle unità target, attualmente non fanno nulla se nonché essere un riferimento per altre unità.

Documentazione.

systemd dispone di una documentazione completa. Far riferimento a http://0pointer.de/blog/projects/systemd-docs.html

Caratteristiche.

systemd fornisce quanto segue:

• aggressive capacità di parallelizzazione usando il socket: Per velocizzare l'intero avvìo e per inizializzare più processi in parallelo, systemd crea la lista dei socket prima di inizializzare il demone, solo dopo passa il socket. Tutti i socket per tutti i demoni sono creati in una sola volta nel sistema init, successivamente vengono avviati. Se un servizio necessita di un altro servizio che non è pienamente inizializzato, allora rimarrà in coda bloccando il client in quella singola richiesta. Ma solo quel client e solo su quella richiesta. Inoltre, dipendenze tra servizi non dovranno più essere configurate per permettere la parallelizzazione: avviando tutti i socket contemporaneamente, il servizio dipendente da un altro sicuramente sarà connesso ai suoi socket.

• attivazione di D-Bus per avviare i servizi: usando l'attivazione bus, un servizio può essere avviato la prima volta all'accesso. La Bus activation inoltre assicura la sincronizzazione minima necessaria per avviare i provider ed i consumer dei servizi D-Bus: avviando nello stesso momento due servizi, se uno è più veloce dell'altro allora D-Bus ne accoda la richiesta.

• offre l'avvìo on-demand dei demoni

• mantiene traccia dei processi usando i cgroups Linux: Ogni processo eseguito ha il proprio cgroup che è molto facile da configurare anche dalle utilities libcgroups ad esempio.

• supporta lo snapshotting e il ripristino dello stato del sistema: Gli Snapshots possono essere usati per salvare/ripristinare lo stato di tutti i servizi e delle unità di init. Principalmente ci sono due casi tipici: permettere all'utente di usare temporaneamente uno specifico stato come l' "Emergency Shell", terminando i servizi correnti e fornisce una facile via per tornare allo stato precedente con tutti i servizi previsti, fermando tutti quelli avviati temporaneamente.

• mantiene i punti di montaggio e di automontaggio: Systemd monitora tutti i punti di montaggio e può essere usato per modificarli. /etc/fstab può essere usato come configurazione addizionale. Usando l'opzione comment= di fstab, è possibile persino marcare le voci in /etc/fstab per lasciare a systemd il controllo dei punti di montaggio..

• implementa una logica di controllo del servizio basata sulle dipendenze: Systemd supporta diversi tipi di dipendenze tra servizi (o unità), usando le opzioni After/Before, Requires e Wants nei file di configurazione per fissare l'ordine d'attivazione delle unità. Requires e Wants esprimono una richiesta di dipendenza positiva, sia obbligatoria che facoltativa. C'é Conflicts che esprime una richiesta di dipendenza negativa ed altre meno usate. Come controllo transazionale, se una unità è richiesta per avviare o terminare, systemd la aggiungerà insieme a tutte le sue dipendenze ad una transazione temporanea, verificandone la consistenza (o l'ordine attraverso After/Before di tutte le unità cycle-free). Se non lo è, systemd proverà a sistemarla ed a rimuovere le operazioni non essenziali dalla transizione che potrebbero rimuovere il loop.

e:

• Per ogni processo generato, systemd controlla: L'ambiente, i limiti delle risorse, directory working e root, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, group id supplementari, directory leggibili/scrivibili/inaccessibili, mount flags condivise/private/secondarie, capabilities/bounding set, secure bits, CPU scheduler reset of fork, /tmp name-space privati, controllo cgroup per vari sottosistemi. Inoltre, è possibile connettere facilmente stdin/stdout/stderr dei servizi a syslog, /dev/kmsg, arbitrary TTYs. Se connesso ad un TTY per input, systemd farà in modo che un processo ottenga un accesso esclusivo, opzionalmente attendendo o forzando.

• I file di configurazione nativi usano la sintassi dei ben conosciuti file .desktop: E' una sintassi semplice per la quale il parser esiste già in molti software frameworks. Inoltre, questo permette di fare affidamento su strumenti già esistenti per i18n per la descrizione dei servizi e simili, senza la necessità per gli amministratori di imparare una nuova sintassi.

Systemadm.

C'é un UI minimale, systemadm, che permette di avviare/fermare/esaminare i servizi. E' parte del pacchetto systemd-gtk. E' ancora in lavorazione e non è funzionale, ma utile come strumento di debugging. E' scritto in Vala. Non usarlo per adesso se non si è sviluppatori

(... e più avanzate)

• Compatibilità con SysV init scripts: Si avvantaggia di LSB e degli headers Red Hat chkconfig se disponibili; altrimenti usa le informazioni disponibili, come le priorità di avv'o in /etc/rc.d. Questi script init vengono semplicemente considerati una fonte di configurazione differente, facilitano il percorso d'aggiornamento ai servizi systemd.

• file di configurazione /etc/fstab: solo un'altra fonte di configurazione. Usando l'opzione comment= di fstab, è possibile marcare le voci in /etc/fstab per far controllare a systemd i punti di automontaggio.

• Supporta un semplice meccanismo di templating/instance: Per esempio, invece di avviare sei file di configurazione per sei gettys, si ha solo un file getty@.service che crea un'instanza a getty@tty2.service e simili. L'interfaccia può essere ereditata dalle dipendenze, ad esempio è facile codificare che un servizio dhcpcd@eth0.service tira dentro avahi-autoipd@eth0.service, mentre lascia la stringa eth0 segnata (wild-carded).

• Compatibilità, in una certa misura, con /dev/initctl. Questa compatibilità è infatti implementata con il servizio FIFO-activated, che semplicemente traduce queste richieste ereditate in richieste D-Bus. Effettivamente significa che i vecchi shutdown, poweroff e comandi simili da Upstart e sysvinit continuano a funzionare con systemd.

• Compatibilità con utmp e wtmp.

Per maggiori dettagli c'é questa lista sul blog dello sviluppatore.