systemd - gestore di sistema e servizi

Contents

  1. systemd - gestore di sistema e servizi
    1. Introduzione
    2. Uso di base
      1. Ottenere informazioni sullo stato del sistema
      2. Gestire servizi
      3. Creare o alterare servizi
    3. Installazione e test
      1. Installazione
      2. Configurazione a fini di test
      3. Configurazione come sistema predefinito
    4. Debug
      1. Unità fallite
      2. systemd si bloccal all'avvio o allo spegnimento
      3. Debug del kernel senza debug di systemd in Jessie
    5. Bug and sistemi di tracciamento dei bug
    6. Problemi conosciuti e soluzioni
      1. Montaggi bind condivisi
      2. La sessione SSH non termina in modo pulito al riavvio o allo spegnimento
      3. Messaggi di avvio mancanti in console(tty1) dopo l'avvio
      4. Cambio di console virtuali e seriali
      5. Processi orfani
    7. Dove ottenere aiuto?
    8. Installazione senza systemd
    9. Risorse Debian
    10. Altre risorse

Introduzione

systemd è un gestore di sistema e servizi per Linux. È il sistema init predefinito per Debian a partire da Debian 8 ("jessie"). systemd è compatibile con script init per SysV e LSB. Può funzionare come rimpiazzo perfetto per sysvinit. Systemd

systemd viene eseguito come demone con PID 1.

Le attività di systemd sono organizzate in unità. Le unità più comuni sono servizi (.service), punti di montaggio (.mount), device (.device), socket (.socket) o temporizzatori (.timer). Per esempio l'avvio del demone Secure SHell viene fatto dall'unità ssh.service.

systemd mette ogni servizio in un gruppo di controllo (cgroup) dedicato che prende il nome dal servizio. I kernel moderni gestiscono l'isolazione dei processi e l'allocazione delle risorse sulla base dei cgroup.

I target sono gruppi di unità. I target richiamano unità per mettere insieme il sistema. graphical.target, per esempio, chiama tutte le unità necessarie per avviare una postazione di laoro con un'interfaccia utente grafica. I target possono costruire uno sopra l'altro oppure dipendere da altri target. All'avvio systemd attiva il target default.target che è un alias per un altro target, come graphical.target.

systemd crea e gestisce i socket usati per la comunicazione tra i componenti del sistema. Per esempio prima crea il socket /dev/log e poi avvia il demone syslog. Questo approccio ha due vantaggi: in primo luogo i processi che comunicano con syslog attraverso /dev/log possono essere avviati in parallelo. Poi i servizi che vanno crash possono essere riavviati senza che i processi che comunicano con essi attraverso socket perdano la loro connessione. Il kernel tiene un buffer della comunicazione mentre il processo si riavvia.

Per maggiori informazioni vedere la pagina originale di systemd.

Uso di base

systemctl è lo strumento principale utilizzato per l'introspezione e il controllo dello stato del gestore di sistema e servizi "systemd". Si può, ad esempio, usare systemctl per abilitare o disabilitare servizi in modo permanente o solo per la sessione corrente. Per maggiori dettagli fare riferimento alla pagina di manuale systemctl(1).

Ottenere informazioni sullo stato del sistema

Visualizzare lo stato del sistema: 

$ systemctl status

Elencare le unità che hanno fallito: 

$ systemctl --failed

Elencare i file di unità installati: 

$ systemctl list-unit-files

Gestire servizi

Elencare tuti i servizi in esecuzione: 

$ systemctl

Attivare il servizio "esempio1" immediatamente: 

# systemctl start esempio1

Deattivare il servizio "esempio1" immediatamente: 

# systemctl stop esempio1

Riavviare il servizio "esempio1" immediatamente: 

# systemctl restart esempio1

Visualizzare lo stato del servizio "esempio1": 

# systemctl status esempio1

Abilitare l'avvio di "esempio1" all'avvio di sistema: 

# systemctl enable esempio1

Disabilitare l'avvio di "esempio1" all'avvio di sistema: 

# systemctl disable esempio1

Creare o alterare servizi

Le unità sono definite da singoli file di configurazione chiamati file di unità. Il tipo di unità è riconosciuto dal suffisso del nome del file, .mount nel caso di un punto di mount. I file di unità forniti da Debian sono posizionati nella directory /lib/systemd/system directory. Se esiste un file di unità locale con un nome identico nella directory /etc/systemd/system, questo avrà la precedenza e systemd ignorerà il file nella directory /lib/systemd/system. Alcune unità vengono create da systemd senza che esista un file di unità nel file system.

Gli amministratori di sistema dovrebbero mettere i file di unità nuovi o quelli altamente personalizzati in /etc/systemd/system.

Per piccoli aggiustamenti ad un file di unità gli amministratori di sistema dovrebbero usare la funzionalità "drop-in directory" (documentata in systemd.unit(5)).

Ecco un esempio: 

# cat /etc/systemd/system/name.service.d/local.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/name-service --my-options

Per informazioni su come scrivere servizi propri, vedere systemd/Services.

Installazione e test

systemd è stato incluso in Debian wheezy come anteprima tecnologica. Assicurarsi di stare usando Debian jessie o una successiva per ottenere una versione recente di systemd.

Installazione

Per installare systemd eseguire: 

# apt-get update
# apt-get install systemd

Questo installa i pacchetti di systemd ma non configura systemd come sistema init.

Configurazione a fini di test

Per testare systemd prima di passare ad usarlo in modo predefinito si può aggiungere il seguente parametro d'avvio al kernel: 

init=/lib/systemd/systemd

Ciò può essere fatto nel menu di grub per un solo avvio: premere "e" nel menu di grub e aggiungere quanto detto nella riga del kernel. Per esempio, a seconda delle opzioni richieste dal proprio particolare sistema, potrebbe essere una cosa simile a: 

linux   /vmlinuz-3.13-1-amd64 root=/dev/mapper/root-root init=/lib/systemd/systemd ro quiet

Se il PID 1 è systemd allora il sistema è in esecuzione con systemd.

Configurazione come sistema predefinito

Per utilizzare systemd si deve installare anche systemd-sysv che fornisce i collegamenti simbolici per /sbin/init. È raccomandato di eseguirlo quando il sistema è già in esecuzione con systemd, come descritto nella sezione precedente. 

# apt-get install systemd-sysv

Per avviare il sistema con il systemd appena installato basta riavviare. 

# reboot

Se si esegue un kernel compilato personalmente assicurarsi di avere 2.6.39 o successivo e abilitare le seguenti opzioni: 

 * CONFIG_DEVTMPFS=y
 * CONFIG_CGROUPS=y
 * CONFIG_AUTOFS4_FS=[y|m]
 * CONFIG_IPV6=[y|m], opzionale, ma altamente raccomandato
 * CONFIG_FANOTIFY=y, opzionale, necessario per il readahead di systemd, disponibile nel kernel Linux >= 2.6.37.

Per un elenco aggiornato vedere la sezione "REQUIREMENTS" nel file README degli autori originali a monte.

Debug

Unità fallite

In alcuni casi le unità entrano in uno stato detto di fallimento. Il comando status può essere utilizzato per scoprire alcuni dettagli: 

$ systemctl status <NOMEUNITA>

Le unità fallite possono essere manualmente ripulite: 

# systemctl reset-failed

systemd si bloccal all'avvio o allo spegnimento

A volte è necessario investigare sul perché systemd si blocca all'avvio o durante un riavvio o uno spegnimento.

Soluzione n.0: rimuovere "quiet" dalla riga di comando del kernel (a volte chiamata "cmdline" o "grub line")

Soluzione n.1: aumentare la prolissità utilizzando la riga di comando (cmdline): aggiungere "systemd.log_target=kmsg systemd.log_level=debug"

Naturalmente si può avere una soluzione "temporanea" persistente: 

[ /etc/default/grub ]
GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug" <--- aggiungere qui (decommentando si può facilmente passare al debug)

# update-grub

Soluzione n.2: aumentare la prolissità usando /etc/systemd/system.conf 

LogLevel=debug           <--- decommentare questa riga e usare  "debug" (predefinito: commentato e con "info")
LogTarget=syslog-or-kmsg <--- decommentare questa riga (predefinito: commentato)

Soluzione n.3: avviare una shell di emergenza: aggiungere systemd.unit=rescue.target o semplicemente 1 (il numero uno) alla riga di comando del kernel.

Soluzione n.4: abilitare la shell di debug: eseguire systemctl enable debug-shell.service. (Lo si può fare in un ambiente chroot dopo aver avviato un sistema di ripristino.) Questo avvia una shell root su TTY 9.

SUGGERIMENTO: "man systemd" e "man systemd-system.conf"

SUGGERIMENTO: informazioni esaustive di debug su systemd sono disponibili in questa pagina di FreeDesktop.

SUGGERIMENTO: HCome controllare i parametri/opzioni della riga di comando del kernel? 

# cat /proc/cmdline

NOTA: per LogLevel (vedere systemd(1) e systemd-system.conf(5)):

"Impostare il livello di log. Come argomentio accetta un livello di log numerico o anche i noti nomi simbolici di syslog(3) (in minuscolo): emerg, alert, crit, err, warning, notice, info, debug."

SUGGERIMENTO: tenere una copia di /sbin/init dal pacchetto sysvinit in caso di ripristino (così si può usare init=/sbin/init.sysvinit nella riga di comando del kernel)! 

# cp -av /sbin/init /sbin/init.sysvinit <--- Prima di installare il pacchetto systemd-sysv

Vedere anche https://fedoraproject.org/wiki/How_to_debug_Systemd_problems

Debug del kernel senza debug di systemd in Jessie

Usare il vecchio parametro "debug" del kernel in Jessie attiva il log di debug di systemd oltre al log di debug del kernel. Per ottenere il vecchio comportamento, non usare "debug", ma usare invece il parametro "loglevel=7" del kernel.

Bug and sistemi di tracciamento dei bug

Problemi conosciuti e soluzioni

Montaggi bind condivisi

Il comportamento predefinito dei montaggi bind cambia in systemd. Il kernel Linux rende i montaggi bind di tutto ciò che è sotto / PRIVATI. Systemd cambia tutto ciò in CONDIVISO.

Perciò quando si esegue: 

    mount --bind / $CHROOT
    mount --bind /dev/ $CHROOT/dev
    umount $CHROOT/dev

allora /dev viene smontata anche nel sistema base/genitore!

Ciò che si può fare ora invece è: 

    mount --bind --make-rslave / $CHROOT
    mount --bind --make-rslave /dev/ $CHROOT/dev

ciò propaga i cambiamenti di montaggio (anche le opzioni di montaggio) nel sistema base/genitore nella $CHROOT ma non dalla $CHROOT indietro al genitore.

La ragione della modifica al comportamento predefinito può essere trovata nel bug 739593, in particolar modo nel commento di Lenart che contiene.

La sessione SSH non termina in modo pulito al riavvio o allo spegnimento

Se si riavvia o si spegne la macchina via ssh può succedere che la propria sessione non termini correttamente lasciando con un terminale non reattivo fino a che non è passato un lungo tempo di timeout. C'era il bug 751636 a questo proposito. Il problema era aggirabile installando: 

    apt-get install libpam-systemd

che terminerà la sessione ssh prima della disattivazione della rete. Notare che ciò richiede l'abilitazione di PAM in sshd.

Messaggi di avvio mancanti in console(tty1) dopo l'avvio

Con systemd console(tty1) è gestita diversamente e se si era abituati a controllarla per vedere come era andato l'avvio ora si vedranno un paio di righe poco informative.

Per ottenere l'intera trascrizione dell'avvio di sistema sulla console è necessario effettuare due passaggi:

1. Aggiungere alle opzioni del kernel systemd.show_status=1, per esempio attraverso /etc/default/grub: 

    GRUB_CMDLINE_LINUX_DEFAULT="quiet systemd.show_status=1"

ed eseguire update-grub2.

2. Creare il file /etc/systemd/system/getty@tty1.service.d/noclear.conf con il seguente contenuto: 

[Service]
TTYVTDisallocate=no

per disabilitare la pulizia del terminale all'invocazione di getty.

Cambio di console virtuali e seriali

Chi era abituato a modificare inittab per abilitare o disabilitare console virtuali o seriali avrà notato che tale file non esiste più sulle installazioni pulite. Tutto ciò viene gestito ora direttamente attraverso systemd. Per esempio, si può abilitare una console seriale su COM1 con: 

systemctl enable serial-getty@ttyS0.service
systemctl start serial-getty@ttyS0.service

Tuttavia è generalmente preferibile aggiungere console=ttyS0 alla riga di comando del kernel dato che ciò abilita anche l'output del kernel ai riavvii. Per esempio, per GRUB, ciò viene fatto aggiungendo quando segue a /etc/default/grub: 

GRUB_CMDLINE_LINUX="console=ttyS0"

... ed eseguendo update-grub. Ciò avrà però effetto solamente al prossimo riavvio.

Notare anche che Linux gestisce più console per l'output, ma solo una per l'input; l'ultima indicata (o quella predefinita se nessuna viene indicata) dalla riga di comando del kernel specifica quale viene usata per l'input e tutte sono usate per l'output. Ad esempio per GRUB: 

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0"

Ciò farà sì che, dopo l'esecuzione di update-grub e il riavvio, si abbia l'input da console da /dev/ttyS0 e l'output sia in quel device sia in /dev/tty0. Notare anche che possono essere specificare anche parametri seriali, es.: 

GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,9600n8"

Processi orfani

Dato che gestisce le sessioni utente (prendendo il ruolo di X o altri componenti) systemd può cambiare leggermente il modo in cui i processi sopravvivono ad un logoff. In modo predefinito, quando X viene chiuso, tutti i processi dovrebbero terminare e systemd ripulisce la sessione, ma ci sono alcuni casi particolari in cui certi processi non fanno correttamente pulizia.

Si può configurare il modo in cui systemd gestisce i processi residui con il parametro KillUserProcesses= in logind.conf. Impostandolo a yes, i processi verranno uccisi in modo forzato quando termina la sessione. Notare che ciò rende difettosi strumenti come screen o tmux, a meno che non siano configurati per essere eseguiti sotto una separata unità user@.service e se enable-linger è impostato a yes in loginctl. Un semplice modo per farlo al volo è di eseguire il programma in un "ambito transitorio" usando systemd-run: 

systemd-run --scope --user screen

Ora le sessioni normali dovrebbero fare pulizia e i problemi relativi dovrebbero essere risolti senza dover ricorrere al metodo violento KillUserProcesses=yes. Un buon modo per elencare i processi che sono interessati da ciò è di raggrupparli per "control group", con il comando systemd-cgls: 

systemd-cgls

Alcune applicazioni per le quali è noto che si comportano male:

Dove ottenere aiuto?

Systemd è un progetto giovane con una forte attenzione alla risoluzione dei problemi in modo indipendente dalla distribuzione.

I canali specifici di Debian includono:

Svariate altre distribuzioni usano systemd:

Installazione senza systemd

Jessie installa systemd in modo predefinito nelle nuove installazioni. Se si desiderasse fare l'installazione senza systemd, cioè usare invece sysvinit-core (vecchio init sysV5) è possibile usare preseed per sostituire systemd con sysvinit alla fine dell'installazione (ciò tuttavia probabilmente non funzionerà se si seleziona uno degli ambienti desktop che richiedono funzionalità specifiche di systemd). Se si usa già un file preseed assicurarsi solamente di impostare il valore di preseed 

preseed/late_command="in-target apt-get install -y sysvinit-core"

Se non si usa un file di preseed ciò può essere aggiunto invece agli argomenti di avvio premendo il tasto di tabulazione (TAB) al menu di avvio sulla voce desiderata e aggiungendo la riga di preseed soprastante alla fine del comando di avvio.

Ci potrebbero essere comunque alcuni frammenti di systemd installati, ma almeno l'init stesso non sarà systemd e la pulizia di ogni frammento rimasto non dovrebbe essere troppo difficile.

Risorse Debian

Altre risorse

CategoryPermalink