Difference between revisions of "Systemd (Italiano)"

From ArchWiki
Jump to: navigation, search
(Allineamento al 07.11.2012 18:35)
m (Allineamento al 08.11.2012 01:35)
Line 214: Line 214:
 
=== ACPI power management ===
 
=== ACPI power management ===
  
Systemd gestisce degli eventi [http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface ACPI] relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di {{ic|/etc/systemd/logind.conf}}:
+
Systemd gestisce degli eventi [[Wikipedia:Advanced_Configuration_and_Power_Interface|ACPI]] relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di {{ic|/etc/systemd/logind.conf}}:
  
 
* {{ic|HandlePowerKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
 
* {{ic|HandlePowerKey}} : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio

Revision as of 21:12, 8 November 2012

Sommario help replacing me
Tratta di come installare e configurare systemd
Articoli correlati
Systemd/Services
Systemd_FAQ_(Italiano) - FAQs
Init Rosetta
udev

Dalla pagina web del progetto: '"systemd è un gestore di sistema e di servizi per Linux, compatibile con gli initscript SysV e LSB. systemd fornisce una notevole capacità di parallelizzazione, usa socket e D-Bus per l'avvio dei demoni, offre un avvio su richiesta dei demoni, tiene traccia dei processi con l'utilizzo del control groups di Linux, supporta lo snapshotting e il restore dello stato del sistema, mantiene i punti di mount e di automount e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze. Può funzionare come rimpiazzo totale di sysvinit."

Nota: Per una dettagliata spiegazione del motivo per cui Arch è passato a systemd, leggi questo post.

Leggi anche l' articolo su Wikipedia.

Contents

Cose da considerare prima di passare a systemd

  • E' fortemente consigliato passare al nuovo sistema di configurazione degli initscripts descritto nell' articolo relativo a rc.conf. Una volta eseguita questa configurazione, si è fatto la maggior parte del lavoro che occorre per passare a systemd.
  • Documentarsi su systemd.
  • Notare che systemd possiede un sistema journal che rimpiazza syslog, tuttavia i due possono coesistere. Vedi la sezione relativa al journal più sotto.
  • Anche se systemd può rimpiazzare le funzionalità di cron, acpid, o xinetd, non c'è nessun bisogno di abbandonare l'uso dei demoni tradizionali a meno con non lo si voglia.

Installazione

Systemd può essere installato a fianco del normale pacchetto initscripts di Arch, e può essere abilitato/disabilitato aggiugendo/rimuovendo init=/usr/lib/systemd/systemd dai parametri del kernel.

Una installazione mista systemd/sysvinit/initscripts

E' possibile mantenere sia systemd che SysVinit installati usando gli stessi files di configurazione cosicché da poter tornare in dietro liberamente:

  1. Togliere il formato di configurazione di initscripts ormai deprecato (dovrebbe esserci un avvertimento al boot) mediante una configurazione nativa di systemd, e riavviare per verificare che gli initscripts funzionino come ci si aspetta.
  2. Installare systemd dai repo ufficiali.
  3. Aggiungere init=/usr/lib/systemd/systemd ai parametri del kernel nel bootloader.
  4. Riavviare.

Systemd avvierà i demoni in /etc/rc.conf e avvierà /etc/rc.local e /etc/rc.local.shutdown all'avvio o allo spegnimento (vedi #Emulazione_degli_Initscripts più sotto). Se il vecchio supporto per DAEMONS in rc.conf o lo script in rc.local non è necessario, il corrispondente servizio li disabiliterà.

Se si sta usando un login manager (SLiM, GDM, etc.) avviandolo da /etc/inittab non partirà, in quanto systemd non usa inittab. La pagina del wiki per i login manager spiega come aggiungerli ai servizi di systemd.

Attenzione: In caso si abbiano demoni nella riga DAEMONS che possiedono files service nativi di systemd, quest'ultimi saranno utilizzati automaticamente. Tuttavia, se il nome del servizio e il nome dello script rc non corrispondono, questo non funzionerà e occorre assicurarsi che solo uno dei due (preferibilmente quello nativo) sia attivato.
Attenzione: Systemd è un processo asincrono, confrontato con quello di avvio sequenziale tramite DAEMONS. In particolare network essendo un servizio datato, può avviarsi troppo tardi rispetto la partenza delle interfacce richieste da altri servizi. Si consiglia di passare a netcfg o NetworkManager prima di inoltrarsi in systemd.

Una installazione mista systemd/initscripts

E' possibile rimpiazzare sysvinit con systemd, ma mantenere gli initscripts nel caso che alcuni rc scripts non abbiano l'equivalente in systemd (vedere #Initscripts emulation più sotto).

  1. Seguire le istruzioni per una installazione mista systemd/sysvinit/initscripts
  2. Attivare i demoni formalmente elencati in /etc/rc.conf con systemctl enable "daemonname". Per una traduzione dei demoni da /etc/rc.conf ai servizi di systemd, vedere: Lista dei demoni e dei servizi. I demoni che non hanno ancora un servizio di systemd equivalente devono essere mantenuti nella riga DAEMONS affinché systemd possa avviarli dal vecchio rc scripts.
  3. Installare systemd-sysvcompat. Questo va in conflitto con sysvinit, e ne chiederà la rimozione.
  4. Rimuovere init=... dai parametri del bootloader in quanto /sbin/init ora è un link simbolico a systemd.
  5. Riavviare.

La sola differenza tra questa modalità e quella di mantenere sysvinit è che tutti i files binari di sysvinit sono rimpiazzati da link simbolici a systemctl. In ogni caso, le funzionalità sono immutate.

Una installazione pura di systemd

Infine, è possibile rimuovere interamente initscripts e sysvinit e usare solo systemd.

  1. Seguire le istruzioni per una installazione mista systemd/initscripts
  2. Accertarsi che non ci siano più demoni avviati dalla riga DAEMONS di /etc/rc.conf e che /etc/rc.local e /etc/rc.local.shutdown siano entrambi vuoti.
  3. Rimuovere il pacchetto initscripts dal sistema.

{{Attenzione|Non rimuovere systemd-sysvcompat finché il pacchetto si trova nel gruppo base.

Informazioni supplementari

  • Se si utilizza quiet nei parametri del kernel, è possibile rimuoverlo durante i primi avvii di systemd per identificare eventuali problemi durante il boot.
  • Con systemd l'aggiunta del proprio utente ai gruppi (optical, audio, scanner, ...) non è più necessaria in parecchi casi. I gruppi possono causare dei problemi di funzionalità. Per esempio il gruppo audio può guastare il cambio utente rapido e permettere alle applicazioni di bloccare il mixer sostware. Ogni accesso con PAM fornisce una sessione logind, la quale per una sessione locale darà i permessi via POSIX ACLs sui dispositivi audio/video, e permette certe operazioni come il montaggio di dischi removibili per mezzo di udisks.
Nota: Systemd-logind rimpiazzaConsoleKit il quale è stato rimosso dai repo, cosicché un sistema può essere avviato con systemd ed essere perfettamente funzionante. Vedere here per maggiori informazioni.

Configurazione nativa

Nota: E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root

Hostname

L'hostname è configurato in /etc/hostname. Il file non contiene il dominio di sistema, se esiste. Per configurare l'hostname:

# hostnamectl set-hostname myhostname

See man 5 hostname e man 1 hostnamectl per dettagli.

Esempio di file:

/etc/hostname
myhostname

Impostazioni locali

Le impostazioni locali di default sono configurate in /etc/locale.conf Per configurare il locale di default:

# localectl set-locale LANG="it_IT.utf8"
	
Nota: Prima di configurare il locale di default, si devono attivare quelle disponibili al sistema decommentandole in /etc/locale.gen e poi eseguendo locale-gen da root. Quella configurata con localectl deve essere una di quelle decommentate in /etc/locale.gen.

Vedere man 1 localectl e man 5 locale.conf per dettagli.

Per ulteriori informazioni vedere Locale.

Esempio di file:

/etc/locale.conf
LANG=it_IT.utf8

Console virtuale

La console virtuale (la mappatura della tastiera, i caratteri della console e la mappatura della console) è configurata in /etc/vconsole.conf:

/etc/vconsole.conf
KEYMAP=it
FONT=
FONT_MAP=
Nota: Da systemd-194, si utilizzano i caratteri integrati nel kernel e la mappatura della tastiera "us" se KEYMAP= e FONT= sono vuoti o non configurati.

Un altro modo di configurare la mappatura della tastiera è:

# localectl set-keymap it

Ciò ha il vantaggio di configurare la tastiera per l'uso in X11.

Vedere man 1 localectl e man 5 vconsole.conf per maggiori dettagli.

Per maggiori informazioni vedere i font per console e configurazione tastiera.

Settare il fuso orario

Il fuso orario è configurato creando un apposito link simbolico in /etc/localtime che punti ad un file di informazioni sulla zona in /usr/share/zoneinfo/. Per farlo automaticamente:

# timedatectl set-timezone Europe/Rome

Leggere man 1 timedatectl e man 5 localtime per maggiori dettagli.

In alternativa creare manualmente il collegamento:

# ln -s ../usr/share/zoneinfo/Europe/Rome /etc/localtime

Orario di sistema

Systemd usa UTC di default per l'orologio hardware.

Suggerimento: E' generalmente consigliato avere il demone Network Time Protocol attivo per mantenere l'orologio di sistema sincronizzato con Internet e con l'orologio del bios.

Orologio hardware in localtime

Se si vuole cambiare l'orologio hardware ad usare l'orario locale (ALTAMENTE SCONSIGLIATO):

# timedatectl set-local-rtc true

Se si vuole riconvertirlo a UTC:

# timedatectl set-local-rtc false

Attenzione che, se l'orologio hardware è configurato a localtime, la gestione dell'orario legale è persa. Se l'orario legale cambia finché il computer è spento il proprio orario sarà sbagliato al prossimo riavvio (ulteriori approfondimenti). I kernel recenti configurano l'orario di sistema dall'orologio hardware direttamente al boot, presupponendo che l'orologio hardware sia impostato a UTC. Questo significa che se l'orologio hardware è su locale l'orologio di sistema sarà prima configurato sbagliato e poi corretto ad ogni boot. Questa è la causa di alcuni noiosi bugs (il tempo che torna indietro è raramente una buona cosa).

Una ragione per permettere che l'orologio hardware sia settato sul'orario locale è quella del dual boot con Windows (il quale usa localtime). Tuttavia, Windows è in grado di gestire l'orario con l'orologio hardware settato su UTC con un semplice aggiustamento del registro di sistema. Quindi, è consigliato che Windows usi UTC, piuttosto che Linux usi localtime. Se si usa UTC su Windows, ricordarsi inoltre di disabilitare l'opzione di Windows "Internet Time Update", al fine di evitare confusione tra windows e l'orologio hardware, nel tentativo di sincronizzazione con l'orario internet. Al contrario, occorre lasciare che Linux sincronizzi l'orario di sistema con l'orario internet attivando il demone NTP, come suggerito precedentemente.

  • Per maggiori informazioni vedere Time.

Moduli del Kernel

Ad oggi, tutti i moduli necessari da caricare sono gestiti automaticamente da udev, cosicché, se non si vuole usare qualcuno dei moduli fuori dal kernel, non c'è bisogno di mettere i moduli che dovrebbero essere caricati al boot in nessun file di configurazione. Tuttavia, ci sono casi in cui si vuole caricare un modulo extra durante il processo di avvio oppure evitare il caricamento di un altro perché il computer funzioni correttamente.

Moduli extra da caricare all'avvio

I moduli extra al kernel da caricare durante il boot sono configurati in una lista statica in /etc/modules-load.d/. Ogni file di configurazione ha il nome nello stile di /etc/modules-load.d/<programma>.conf/. I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO. Le linee vuote o quelle dove il primo carattere che non è uno spazio è # oppure ; sono ignorate. Ad esempio:

/etc/modules-load.d/virtio-net.conf
# Carica virtio-net.ko al boot
virtio-net

vedere man 5 modules-load.d per maggiori dettagli.

Blacklisting

Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli initscripts in quanto è attualmente gestito da kmod. Vedere Blacklist dei moduli per maggiori dettagli.

Montaggio del filesystem

La configurazione di default controlla e monta i filesystems prima di avviare i servizi ai quali occorre che siano montati. Per esempio, systemd automaticamente si assicura che il montaggio di filesystems come NFS o Samba avvenga solo dopo che la rete è attiva. Pertanto, il montaggio dei filesystems, sia locali che remoti, specificati in /etc/fstab dovrebbe funzionare senza problemi.

Vedere man 5 systemd.mount per dettagli.

Automount

  • Se si possiede una grande partizione /home, sarebbe meglio permettere ai servizi che non dipendono da essa di avviarsi durante il controllo di /home. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di /home in /etc/fstab:
noauto,x-systemd.automount

Questo controllerà e monterà /home al primo accesso, e il kernel memorizzerà in un buffer tutti gli accessi ai file in /home finché non sarà pronta.

  • Lo stesso si può applicare al montaggio dei filesystems remoti. Se si desidera montarli successivamente all'accesso occorrerà usare i parametri noauto,x-systemd.automount. In aggiunta, si può usare l'opzione x-systemd.device-timeout=# per specificare un tempo di timeout in caso la risorsa di rete non sia disponibile.
  • Se si hanno filesystems criptati con keyfiles, si può comunque aggiungere il parametro noauto alla corrispondente riga in /etc/crypttab. Systemd non aprirà il supporto corispondente all'avvio, ma aspetterà finché non avverrà un accesso e quindi automaticamente aprirà il keyfile specifico prima di montarlo. Questo potrebbe far risparmiare un po' di secondi al boot se si sta per esempio utilizzando un supporto RAID criptato, in quanto systemd non deve aspettare finché il dispositivo non sarà disponibile. Per esempio:
/etc/crypttab
data /dev/md0 /root/key noauto

LVM

Se si possiede un volume LVM non attivato durante l'initramfs, attivare lvm.service (fornito dal pacchetto lvm2 ):

# systemctl enable lvm

Similmente, se si ha un supporto LVM criptato montato più tardi durante l'avvio (per esempio da /etc/crypttab), attivare lvm-on-crypt.service (anch'esso fornito dal pacchetto lvm2):

# systemctl enable lvm-on-crypt

ACPI power management

Systemd gestisce degli eventi ACPI relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di /etc/systemd/logind.conf:

  • HandlePowerKey : specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
  • HandleSuspendKey : specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
  • HandleHibernateKey : specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
  • HandleLidSwitch : specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.

Le azioni specificate possono essere una qualsiasi di ignore, poweroff, reboot, halt, suspend, hibernate or kexec.

Se queste opzioni non sono configurate, systemd userà quelle di default: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, and HandleLidSwitch=suspend.

Su sistemi che non hanno una configurazione grafica o semplici gestori di finestre come i3 o awesome, può rimpiazzare il demone acpid che è solitamente usato per gestire questi eventi ACPI.

Nell'attuale versione di systemd, le opzioni Handle saranno applicate al sistema finché non saranno "inibite" (temporaneamente spente) da un programma, come un gestore di alimentazione in un DE. Se questi inibitori non sono usati, si può finire in una situazione in cui systemd sospende il sistema , poi al risveglio gli altri gestori di alimentazione lo sospendono di nuovo.

Attenzione: Attualmente, il gestore di alimentazione del più recente KDE è l'unico che possiede i necessari comandi inibitori. Quando li avranno anche gli altri, occorrerà settare l'opzione Handle a ignore se si voglio gestire gli eventi ACPI con GNOME, Xfce, acpid o qualsiasi altro programma. Le nuove versioni stanno implementando tale funzionalità.
Nota: Systemd può anche usare altri backends per la sospensione (come Uswsusp o TuxOnIce), in aggiunta al backend di default del kernel, al fine di mettere il computer in uno stato di sleep o ibernazione.

Sleep hooks

Systemd non usa pm-utils per mettere la macchina a riposo quando usa systemctl suspend o systemctl hibernate, quindi gli hooks di Pm-utils incluso qualsiasi hook personalizzato si sia creato non funzioneranno. Tuttavia, systemd fornisce un meccanismo simile per avviare script personali in base a questi eventi. Systemd avvia tutti gli eseguibili in /usr/lib/systemd/system-sleep/ e passa due argomenti a ognuno di essi:

  • Argument 1: pre o post, a seconda che la macchina si stia addormentando o svegliando
  • Argument 2: suspend o hibernate, dipende da quello che è stato invocato.

Al contrario di Pm-utils, systemd avvierà questi scripts contemporaneamente e non uno dopo l'altro.

L'output di ogni script personalizzato sarà registrato da systemd-suspend.service o systemd-hibernate.service cosicché sarà possibile vedere i propri outputs nel journal:

# journalctl -b -u systemd-suspend

Nota che è possibile usare anche sleep.target, suspend.target o hibernate.target per agganciare le unità allo stato di sospensione invece di usare degli scripts personalizzati.

Un esempio di script personalizzato:

/usr/lib/systemd/system-sleep/example.sh
#!/bin/sh
case $1/$2 in
  pre/*)
    echo "Going to $2..."

    ;;
  post/* )
    echo "Waking up from $2..."
    ;;
esac

Vedere man 7 systemd.special e man 8 systemd-sleep per maggiori dettagli.

I files temporanei

Systemd-tmpfiles mantiene la configurazione dei file in /usr/lib/tmpfiles.d/ e in /etc/tmpfiles.d/ per descrivere la creazione, la pulizia e la rimozione dei files e delle cartelle temporanee e volatili che normalmente risiedono in cartelle come /run o /tmp. Ogni file di configurazione prende il nome nello stile di /etc/tmpfiles.d/<program>.conf. Ciò sovrascriverà ogni file in /usr/lib/tmpfiles.d/ con lo stesso nome.

I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esmpio il demone Samba si aspetta che esista la cartella /var/run/samba per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:

/usr/lib/tmpfiles.d/samba.conf
D /var/run/samba 0755 root root

Tuttavia, tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa /etc/rc.local per disabilitare il risveglio del sistema attraverso dispositivi USB con echo USBE > /proc/acpi/wakeup, si può usare in alternativa il seguente tmpfile:

/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE

Il metodo dei tmpfiles è in questo caso raccomandato da quando systemd non supporta più /etc/rc.local.

Vedi man 5 tmpfiles.d per i dettagli.

Unità

Un file di configurazione di unità racchiude informazioni riguardanti un servizio, un socket, un dispositivo, un punto di montaggio, un punto di automontaggio, un file o una partizione di swap, un obbiettivo di avvio, un percorso del filesystem oppure un controllo schedulato da systemd. La sintassi è ispirata da "XDG Desktop Entry Specification" files di tipo .desktop, che a loro volta richiamano i files .ini di windows.

Vedi man 5 systemd.unit per maggiori informazioni.

Transizione da initscripts a systemd

Emulazione degli Initscripts

L'integrazione con la classica configurazione di Arch è garantita dal pacchetto initscripts. Quando initscripts sono installati in parallelo con systemd, con il sistema che sta eseguondo systemd, systemd farà i seguenti passi:

  1. Analizzare la riga DAEMONS di /etc/rc.conf e avviare tutti i demoni elencati all'avvio
  2. Eseguire /etc/rc.local durante l'avvio
  3. Eseguire /etc/rc.local.shutdown durante lo spegnimento

L'emulazione degli Initscripts vuole essere semplicmente una misura transitoria per facilitare gli utenti a passare a systemd, e eventualmente tornare indietro. Systemd nativo non invoca la configurazione centralizzata in rc.conf, cosicché è raccomandato usare i files di configurazione nativa di systemd, i quali avranno la precedenza su /etc/rc.conf.

Nota: La via raccomandata per rimpiazzare /etc/rc.local è quella di scrivere un file service personalizzato per ogni cosa si desideri avviare al boot. Vedere la sezione corrispondente.
Nota: Se si disabilita Template:Keypress per riavviare in /etc/inittab, occorrerà riconfigurarlo per systemd digitando systemctl mask ctrl-alt-del.target da root.

Abbandonare la riga DAEMONS

Per una configurazione pura di systemd, si dovrebbe rimuovere interamente il file /etc/rc.conf ed avviare i servizi solo tramite systemctl. Per ogni <service_name> nella riga DAEMONS in /etc/rc.conf, digitare:

# systemctl enable <service_name>
Suggerimento: Per una lista dei demoni più usati con la loro equivalenza tra initscripts e systemd, vedere questa tabella.

Se <service_name>.service non esiste:

  • Probabilmente, systemd usa un diverso nome. Per esempio, cronie.service rimpiazza il demone di init crond; alsa-store.service e alsa-restore.service rimpiazzano il demone di init alsa. Un'altra importante differenza è il demone network, il quale è rimpiazzato con un'altra serie di servizi (vedere Configuring Network per maggiori dettagli.)
  • in alternativa, un servizio può non essere disponibile per systemd. In questo caso, bisognerà mantenere rc.conf per avviare il servizio all'avvio.
Suggerimento: E' possibile cercare dentro i pacchetti che contengono gli script di avvio dei demoni i nomi dei servizi. Per esempio:
$ pacman -Ql cronie
[...]
cronie /etc/rc.d/crond                            #Daemon initscript elencato nella riga DAEMONS (non usata in una configurazione "pura" di systemd)
[...]
cronie /usr/lib/systemd/system/cronie.service     #Servizio di systemd corrispondente
[...]
  • Finalmente, alcuni servizi non hanno bisogno di essere esplicitamente attivati dagli utenti. Per esempio, dbus.service sarà automaticamente attivato con l'installazione di dbus-core. alsa-store.service e alsa-restore.service sono anch'essi attivati automaticamente da sistemd. Controllare la lista dei servizi disponibili e del loro stato usando il comando systemctl in questo modo:

systemctl status <service_name>

Uso base di systemctl

Il principale comando usato per controllare systemd è systemctl. Alcuni degli utilizzi possibili sono l'esame dello stato del sistema e la gestione del sistema e dei servizi. Vedere man 1 systemctl per maggiori dettagli

Suggerimento: Si può usare il seguente comando systemctl con lo switch -H <user>@<host> per controllare un'istanza di systemd su una macchina remota. Si userà SSH per connettersi all'istanza remota di systemd.
Nota: systemadm è il frontend grafico ufficiale per systemctl. E' fornito dal pacchetto systemd-ui-gitAUR di AUR.

Analizzare lo stato del sistema

Lista della unità attive:

$ systemctl

oppure:

$ systemctl list-units

Lista delle unità che hanno avuto problemi:

$ systemctl --failed

I file delle unità disponibili possono essere visti in /usr/lib/systemd/system/ e /etc/systemd/system/ (questi ultimi hanno la precedenza sui primi). Si possono vedere le unità installate con:

$ systemctl list-unit-files

Usare le unità

Le unità possono essere, per esempio, servizi (.service), punti di monatggio (.mount), dispositivi (.device) oppure i sockets (.socket).

Quando si usa systemctl, occorre generalmente specificare sempre il nome completo dell'unità compreso il suffisso, per esempio sshd.socket. Esistono tuttavia delle scorciatoie quando si specifica l'unità nei seguenti comandi systemctl:

  • Se non si specifica il suffisso, per systemctl sarà sottointeso .service. Per esempio, netcfg e netcfg.service sono equivalenti.
  • I punti di montaggio saranno automaticamente tradotti nella appropriata unità .mount. Per esempio, specificare /home è equivalente a home.mount.
  • Come i punti di montaggio, anche i dispositivi sono automaticamente tradotti nell'appropriata unità .device, quindi specificare /dev/sda2 è equivalente a dev-sda2.device.

Vedi man systemd.unit per dettagli.

Attivare immediatamente una unità:

# systemctl start <unit>

Fermare immediatamente una unità:

# systemctl stop <unit>

Far ripartire una unità:

# systemctl restart <unit>

Chiedere ad una unità di ricaricare la sua configurazione:

# systemctl reload <unit>

Mostrare lo stato di una unità, compreso se sta funzionando o no:

$ systemctl status <unit>

Controllare se una unità è già attivata o no:

$ systemctl is-enabled <unit>

Attivare l'avvio automatico al boot:

# systemctl enable <unit>
Nota: Se i servizi non hanno una sezione Install, significa, di solito, che sono evocati automaticamente da altri servizi. Me se occorre installarli manualmente usare il seguente comando rimpiazzando foo con il nome del servizio.
# ln -s /usr/lib/systemd/system/"foo".service /etc/systemd/system/graphical.target.wants/

Disattivare l'avvio automatico al boot:

# systemctl disable <unit>

Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):

$ systemctl help <unit>

Power management

Se ci si trova in una sessione locale di systemd-logind e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), systemd automaticamente richiederà la password di root.

Spegnimento e riavvio del sistema:

$ systemctl reboot

Spegnimento del sistema:

$ systemctl poweroff

Spegnimento completo del sistema:

$ systemctl halt

Sospensione del sistema:

$ systemctl suspend

Ibernazione del sistema:

$ systemctl hibernate

Avviare un DE con systemd

Per avviare il login grafico, abilitare il demone del suo Display Manager corrispondente (per esempio KDM). Attualmente esistono i .service per GDM, KDM, SLiM, XDM and LXDM e LightDM.

# systemctl enable kdm

Questo dovrebbe funzionare. Se non dovesse, potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione:

# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target

è sufficiente eliminare il link simbolico e systemd utilizzerà il default.target predefinito (per esempio graphical.target).

# rm /etc/systemd/system/default.target

Usare systemd-logind

Nota: Dal 30 Ottobre 2012, ConsoleKit è stato rimpiazzato da systemd-logind come meccanismo di default per autentificarsi nei DE.

Per controllare lo stato della propria sessione utente, si può utilizzare loginctl. Tutte le azioni di PolicyKit come la sospensione del sistema o il montaggio di dispositivi esterni funzioneranno automaticamente.

$ loginctl show-session $XDG_SESSION_ID

Scrivere i files .service personalizzati

Gestire le dipendenze

Con systemd le dipendenze possono essere risolte progettando le unità correttamente. Il caso più tipico è che l'unità A richieda l'unità B per poter funzionare prima che A parta. In questo caso aggiungere Requires=B e After=B alla sezione [Unit] di A. Se la dipendenza è opzionale aggiungere, invece, Wants=B e After=B. Notare che Wants= e Requires= non includono After=, il che significa che se After= non è specificato, le due unità saranno avviate in parallelo.

Le dipendenze sono di solito posizionate sui .service e non sui .target. Per esempio, network.target è richiamato qualsiasi sia il servizio che configuri l'interfaccia di rete, quindi avviare successivamente la propria unità personalizzata è sufficiente in quanto network.target è avviato comunque.

Type

Ci sono parecchi tipi differenti di avvio da considerare quando si scrive un servizio personalizzato. Ciò è configurato tramite il parametro Type= nella sezione [Service]. Vedere man systemd.service per una spiegazione più dettagliata.

  • Type=simple: systemd presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.
  • Type=forking: systemd presuppone che il servizio deve essere avviato prima il processo sia suddiviso e il genitore sia concluso. Per i classici demoni usare questo tipo a meno che non si sappia che non è necessario, come la maggior parte dei demoni usa il double-forking per segnalare che sono pronti. Occorre pure specificare PIDFile= perché systemd tenga traccia del processo principale.
  • Type=oneshot: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con RemainAfterExit= in modo che systemd consideri il servizio ancora attivo anche dopo che il processo si è concluso.
  • Type=notify: Identico a Type=simple, ma con l'accorgimento che il demone invierà un segnale a systemd quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da libsystemd-daemon.so.
  • Type=dbus: Il servizio è considerato pronto quando lo specificato BusName appare nel sistema di bus si DBus.

Rimpiazzare le unità fornite

Le unità in /etc/systemd/system/ hanno la precedenza su quelle in /usr/lib/systemd/system/. Per mantenere la propria versione di una unità (che non sarà distrutta dopo un aggiornamento), copiare la vecchia unità da /usr/lib/ a /etc/ e fare le proprie modifiche qui. In alternativa si può usare .include per analizzare un servizio esistente e sovrascrivere o aggiungere nuove opzioni. Per esempio, se si vuole semplicemente aggiungere una dipendenza al servizio, si può usare:

/etc/systemd/system/<service-name>.service
.include /usr/lib/systemd/system/<service-name>.service

[Unit]
Requires=<new dependency>
After=<new dependency>

Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:

# systemctl reenable <unit>
# systemctl restart <unit>
Suggerimento: Si può usare systemd-delta per vedere quali unità sono state sovrascritte e quali esattamente sono state modificate.

Evidenziazione della sintassi per le unità di systemd con Vim

L'evidenziazione della sintassi per le unità di systemd con Vim può essere attivata installando vim-systemdAUR da AUR.

Targets

Quello dei "runlevels" è un concetto superato in systemd. Systemd ha il concetto di target (lett. "bersagli") che adempiono uno scopo simile a quello dei runlevel, ma che hanno un comportamento leggermente differente. Ogni target ha un nome anziché un numero ed è usato per raggiungere uno specifico scopo con la possibilità di averne più di uno attivo nello stesso momento. Alcuni targets sono attivati ereditando tutto dei servizi di un altro target e implementandolo di servizi addizionali. Ci sono target che simulano i runlevel di SystemVinit, è così possibile passare da un target all'altro utilizzando il comando telinit RUNLEVEL.

Conoscere il target attuale

Il seguente comando dovrebbe essere usato sotto systemd al posto di runlevel:

$ systemctl list-units --type=target

Creare un target personalizzato

I runlevels sono assegnati ad uno specifico scopo su l'installazione vanilla di Fedora; 0, 1, 3, 5, e 6; hanno una mappatura 1:1 con uno specifico target di systemd. Sfortunatamente non c'è un altrettanto buon metodo per i runlevels definiti dall'utente come 2 e 4. Se si fa uso di questi, si suggerisce di dare un nuovo nome al target di systemd come /etc/systemd/system/<your target> che prenda come base une dei runlevels esistenti (vedi /usr/lib/systemd/system/graphical.target come esempio), creare una cartella /etc/systemd/system/<your target>.wants, e fare un collegamento ai servizi addizionali da /usr/lib/systemd/system/ che si intendono attivare.

Targets table

SysV Runlevel systemd Target Notes
0 runlevel0.target, poweroff.target Ferma il sistema.
1, s, single runlevel1.target, rescue.target Modalità utente singolo (single user).
2, 4 runlevel2.target, runlevel4.target, multi-user.target Definita dall'utente. Preconfigurata a 3.
3 runlevel3.target, multi-user.target Multi-user, non-graphical. Users can usually login via multiple consoles or via the network.
5 runlevel5.target, graphical.target Multi-user, grafica. Solitamente ha tutti i servizi del runlevel 3 con l'aggiunta di un login grafico.
6 runlevel6.target, reboot.target Riavvio
emergency emergency.target Console di emergenza

Cambiare il target corrente

In systemd i targets sono esplicitati per mezzo di "target units". Si possono cambiare così:

# systemctl isolate graphical.target

Questo comando cambierà solamente il target corrente e non avrà nessun effetto sul prossimo avvio. Questo è equivalente ai comandi telinit 3 oppure telinit 5 in Sysvinit.

Cambiare il target predefinito all'avvio

Il target standard è default.target, che è abbinato in modo predefinito a graphical.target (che corrisponde al vecchio runlevel 5). Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:

Suggerimento: L'estensione .target può essere tralasciata.
  • systemd.unit=multi-user.target (che corrisponde al vecchio runevel 3),
  • systemd.unit=rescue.target (che corrisponde al vecchio runevel 1).

In alternativa si può lasciare il bootloader inalterato e cambiare default.target. Ciò può essere fatto usando systemctl:

# systemctl enable multi-user.target

L'effetto di questo comando si nota nell'output di systemctl; viene creato un link simbolico al nuovo target predefinito /etc/systemd/system/default.target. Questo funziona solo se:

[Install]
Alias=default.target

si trova nel file di configurazione del target. Attualmente, sia multi-user.target che graphical.target lo possiedono.

Il Journal

Fin dalla versione 38 systemd possiede un proprio sistema di log chiamato journal. Tuttavia, far funzionare il demone syslog non è più richiesto. Per leggere il log si usa:

# journalctl

Di default (quando Storage= è configurato a auto in /etc/systemd/journald.conf), il journal scrive in /var/log/journal/. Se la directory /var/log/journal/ non esiste (o per esempio se qualche programma lo cancellasse), systemd non lo creerà automaticamente, ma invece lo scriverà in /run/systemd/journal. Ciò significa che i log saranno persi al riavvio.

Filtrare l' output

journalctl permette di filtrare l'output secondo specifici campi.

Esempi:

Mostra tutti i messaggi di un eseguibile specifico:

# journalctl /usr/lib/systemd/systemd

Mostra tutti i messaggi di uno specifico processo:

# journalctl _PID=1

Mostra tutti i messaggi di una specifica unità:

# journalctl -u netcfg


Vedi man journalctl e systemd.journal-fields per dettagli.

Limiti alla dimensione del journal

Se il journal è persistente (non volatile) la sua dimensione è fissata al 10% della dimensione del rispettivo file system. Per esempio con /var/log/journal allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal. La dimensione massima del journal persistente può essere controllata attraverso SystemMaxUse in /etc/systemd/journald.conf, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:

SystemMaxUse=50M

Fare riferimento a man journald.conf per maggiori dettagli.

Journald coesistente con syslog

La compatibilità con il classico syslog è fornita dal socket /run/systemd/journal/syslog, attraverso il quale passano tutti i messaggi. Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a /dev/log (official announcement). Il pacchetto syslog-ng dei repo ufficiali automaticamente fornisce la necessaria configurazione.

# systemctl enable syslog-ng

Ottimizzazioni

Analizzare il processo di boot

systemd-analyze

Systemd fornisce una utilità chiamata systemd-analyze che permette di analizzare il proprio processo d'avvio al fine di evidenziare quali unità stanno causando rallentamenti nel processo di avvio stesso. E' possibile quindi ottimizzare il sistema tenendo conto di ciò. Occorre installare python2-dbus e python2-cairo per usarlo.

Per vedere quanto tempo ha impiegato il boot del kernelspace e dello userspace, semplicemente si usi:

$ systemd-analyze
Suggerimento: Per vedere quanto tempo è trascorso nell' initramfs, aggiungere l'aggancio a timestamp al parametro HOOKS in /etc/mkinitcpio.conf e, con root, ricostruire l'initramfs con mkinitcpio -p linux

Per elencare le unità avviate, ordinate a seconda del tempo che impiegano ad avviarsi:

$ systemd-analyze blame

Si può inoltre creare un file SVG che descriva il processo di boot graficamente, similmente a Bootchart:

$ systemd-analyze plot > plot.svg

Usare bootchart

E' possibile usare una versione di bootchart per visualizzare la sequenza di boot. Da quando non è più possibile inserire un secondo "init" nel comando del kernel non c'è più la possibilità di usare alcuna configurazione standard di bootchart. Tuttavia il pacchetto bootchart2AUR di AUR nasce con un non documentato service di systemd. Dopo aver installato bootchart2 fare:

# systemctl enable bootchart

Leggere la documentazione di bootchart per ulteriori dettagli sull'uso di questa versione di bootchart.

Readahead

Systemd nasce con la propria implementazione di readahead , questo dovrebbe principalmente migliorare il tempo d'avvio. Tuttavia, in relazione alla versione del kernel e al tipo di disco rigido, i tempi possono variare (per esempio potrebbe essere più lento). Per attivarlo, fare:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

Ricorda che prima che readahead sprigioni la sua magia, occorre riavviare un paio di volte.

Avvio anticipato dei servizi

Una caratteristica centrale di systemd è l'attivazione di D-Bus e dei socket, il ché provoca l'avvio dei servizi al primo accesso, e generalmente è una cosa positiva. Tuttavia, se si è a conoscenza che un servizio (come UPower) sarà sempre avviato durante il boot, il tempo di avvio potrà essere ridotto avviandolo il prima possibile. Ciò può essere ottenuto (se il servizioè impostato per ciò, e nella maggior parte dei casi lo è) mediante l'immissione di:

# systemctl enable upower

Questo provocherà l'avvio di UPower al più presto possibile, senza causare gare con l'attivazione dei socket o di D-Bus.

Diminuire l'output

Cambiare verbose in quiet nella riga del kernel del bootloader. Per certi sistemi, particolarmente quelli che utilizzano un SSD, il rallentamento delle prestazioni di TTY e attualmente un collo di bottiglia, quindi la diminuzione dell'output significa velocizzare l'avvio.

Tasti di scelta rapida della Shell

La gestione dei demoni tramite systemd richiede un po' più digitazione per realizzare i comandi come l'avvio, lo stop, l'attiavzione, il controllo dello stato, ecc. Le seguenti funzioni possono essere aggiunte a quelle nel file ~/.bashrc per semplificare le interazioni con systemd e per migliorare l'esperienza complessiva.


# comandi semplificati di systemd, per esempio "sudo systemctl stop xxx" - > "0.stop xxx"
if ! systemd-notify --booted;
then  # for not systemd
    0.start() {
        sudo rc.d start $@
    }

    0.restart() {
        sudo rc.d restart $@
    }

    0.stop() {
        sudo rc.d stop $@
    }
else
# start systemd service
    0.start() {
        sudo systemctl start $@
    }
# restart systemd service
    0.restart() {
        sudo systemctl restart $@
    }
# stop systemd service
    0.stop() {
        sudo systemctl stop $@
    }
# enable systemd service
    0.enable() {
        sudo systemctl enable $@
    }
# disable a systemd service
    0.disable() {
        sudo systemctl disable $@
    }
# show the status of a service
    0.status() {
        systemctl status $@
    }
# reload a service configuration
    0.reload() {
        sudo systemctl reload $@
    }
# list all running service
    0.list() {
        systemctl
    }
# list all failed service
    0.failed () {
        systemctl --failed
    }
# list all systemd available unit files
    0.list-files() {
        systemctl list-unit-files
    }
# check the log
    0.log() {
        sudo journalctl
    }
# show wants
    0.wants() {
        systemctl show -p "Wants" $1.target
    }
# analyze the system
    0.analyze() {
        systemd-analyze $@
    }
fi

Correzione di errori

Lo spegnimento e il riavvio sono terribilmente lunghi

Se il processo di spegnimento impiega molto tempo (oppure sembra bloccarsi) probabilmente la colpa è da attribuirsi alla mancata chiusura di un servizio. Systemd attende del tempo per la chiusura di ogni servizio prima di chiuderlo forzatamente. Per vedere se si soffre di questo problema vedere questo articolo.

Vedi anche