systemd (Italiano) - ArchWiki

Jump to content

# systemd (Italiano)

10 languages

- Deutsch
- English
- Español
- Suomi
- Français
- Magyar
- 日本語
- Português
- Русский
- 中文（简体）

From ArchWiki

Translation Status: This article is a localized version of systemd. Last translation date: 2024-02-20. You can help to synchronize the translation, if there were changes in the English version.

Articoli correlati

- /User (Italiano)
- /Timers (Italiano)
- /Journal (Italiano)
- /FAQ (Italiano)
- init (Italiano)
- udev (Italiano)
- Improving performance (Italiano)/Boot process (Italiano)
- Allow users to shutdown (Italiano)

Dalla pagina web del progetto:

  systemd è una suite di elementi costruttivi di base per un sistema Linux. Fornisce un'infrastruttura di gestione dei servizi e del sistema che viene eseguita come PID 1 e avvia il resto del sistema. systemd offre funzionalità di parallelizzazione particolarmente aggressive, utilizza l'attivazione di socket e D-Bus per l'avvio dei sistemi, permette di avviare i demoni su una base on-demand, tiene traccia dei processi utilizzando i gruppi di controllo del kernel Linux, gestisce i punti di mount e di automount, e implementa un'elaborata logica di controllo transazionale dei servizi basata sulle dipendenze. systemd supporta gli script di init SysV e LSB e opera in sostituzione di sysvinit. Altri componenti includono un demone di logging, utilità per il controllo di elementi di base della configurazione del sistema quali hostname, data, localizzazione, conservazione di un elenco degli utenti che hanno effettuato il login ed esecuzione di contenitori e macchine virtuali, account di sistema, cartelle e impostazioni di runtime, e demoni per la gestione di elementi semplici della configurazione di rete, sincronizzazione dell'ora con la rete, inoltro dei log, e risoluzione dei nomi.

Storicamente, ciò che è chiamato "servizio" da systemd era in precedenza conosciuto come demone: qualunque programma che sia in esecuzione come processo in "background" (in assenza di un terminale o di un'interfaccia utente), che di norma rimane in attesa che si verifichino specifici eventi e offre servizi. Un buon esempio è un server web che attende una richiesta per fornire una pagina, o un server ssh che attende che qualcuno tenti di effettuare il login. Mentre in questi casi si tratta di applicazioni complete, sono presenti demoni il cui lavoro non è visibile. I demoni vengono utilizzati per compiti quali la scrittura di messaggi in un file di log (ad es. `syslog`, `metalog`) o il mantenimento di valori accurati per l'ora di sistema (ad es. ntpd). Per maggiori informazioni vedere daemon(7).

Nota: Per una spiegazione dettagliata delle ragioni alla base della decisione di Arch di passare a systemd, vedere questo post sul forum.

## Utilizzo di base di systemctl

Il comando principale utilizzato per analizzare e controllare systemd è systemctl. Le sue funzioni sono esaminare lo stato del sistema e gestire il sistema stesso e i relativi servizi. Vedere systemctl(1) per maggiori dettagli.

Suggerimento:

- È possibile utilizzare tutti i seguenti comandi systemctl con lo switch `-H user@host` per controllare un'istanza systemd su una macchina remota. Questa funzione utilizzerà SSH per connettersi all'istanza remota di systemd.
- Gli utenti Plasma possono installare systemdgenie come interfaccia grafica per systemctl. Una volta installato, il modulo verrà aggiunto nella categoria di programmi Sistema.

### Utilizzo delle unità

Le unità includono di norma, tra gli altri, servizi (.service), punti di mount (.mount), dispositivi (.device) e socket (.socket).

Quando si utilizza systemctl, è generalmente necessario specificare il nome completo del file dell'unità, incluso il suffisso, ad esempio `sshd.socket`. Sono tuttavia disponibili alcune forme abbreviate per specificare l'unità nei seguenti comandi systemctl:

- Se non si specifica il suffisso, systemctl darà per sottinteso il suffisso .service. Ad esempio, `netctl` e `netctl.service` sono equivalenti.
- I punti di mount verranno tradotti automaticamente nell'appropriata unità .mount. Ad esempio, specificare `/home` è equivalente a `home.mount`.
- Analogamente ai punti di mount, i dispositivi vengono automaticamente tradotti nell'unità .device appropriata, pertanto specificare `/dev/sda2` è equivalente a `dev-sda2.device`.

Vedere systemd.unit(5) per maggiori dettagli.

Nota: Alcuni nomi di unità contengono un carattere `@` (ad es. `nome@stringa.service`): ciò significa che si tratta di istanze di un'unità modello, il cui nome file effettivo non contiene la parte `stringa` (ad es. `nome@.service`). L'elemento `stringa` è detto identificatore di istanza, ed è simile a un argomento passato all'unità modello quando questa viene richiamata mediante il comando systemctl: nel file dell'unità andrà a sostituire l'elemento di specificazione `%i`. Per essere più precisi, prima di tentare di assegnare un'istanza all'unità modello `nome@.suffisso`, systemd cercherà effettivamente un'unità esattamente con il nome file `nome@stringa.suffisso`, benché per convenzione questo tipo di conflitto si verifichi raramente, in quanto la maggior parte dei file unità contenenti un carattere `@` sono concepiti come modelli. Pertanto, se un'unità modello viene chiamata senza un identificatore di istanza, restituirà in genere un errore (fatta eccezione per determinati comandi systemctl, come `cat`).

I comandi riportati nella tabella di seguito operano sulle unità di sistema dal momento che `--system` è sottinteso come impostazione di default per systemctl. Per operare invece sulle unità utente (per lutente che effettua la chiamata), utilizzare systemctl --user senza privilegi di root. Vedere anche systemd (Italiano)/User (Italiano)#Configurazione di base per abilitare/disabilitare le unità utente per tutti gli utenti.

Suggerimento:

- La maggior parte dei comandi funziona anche specificando unità multiple, vedere systemctl(1) per maggiori informazioni.
- Lo switch `--now` può essere utilizzato in associazione con `enable`, `disable`, e `mask` rispettivamente per avviare, arrestare o mascherare l'unità immediatamente anziché dopo il reboot.
- Un pacchetto può offrire unità per diverse finalità. Se si è appena installato un pacchetto, è possibile utilizzare il comando `pacman -Qql pacchetto | grep -Fe .service -e .socket` per verificare la presenza di dette unità.

Azione | Comando | Nota
--- | --- | ---
Analisi dello stato del sistema
Mostra lo stato del sistema | `systemctl status` |
Elenca le unità in esecuzione | `systemctl` oppure `systemctl list-units` |
Elenca le unità con errori | `systemctl --failed` |
Elenca il file unità installati1 | `systemctl list-unit-files` |
Mostra lo stato del processo per un PID | `systemctl status pid` | cgroup slice, memoria e parent
Controllo dello stato dell'unità
Mostra una pagina del manuale associata a un'unità | `systemctl help unità` | se supportato dall'unità
Stato di un'unità | `systemctl status unità` | inclusa l'indicazione se l'unità è in esecuzione o no
Verifica dell'abilitazione di un'unità | `systemctl is-enabled unità` |
Avvio, riavvio, ricaricamento di un'unità
Avvio immediato di un'unità | `systemctl start unità` come root |
Arresto immediato di un'unità | `systemctl stop unità` come root |
Riavvio di un'unità | `systemctl restart unità` come root |
Ricaricaemnto di un'unità e della relativa configurazione | `systemctl reload unità` come root |
Ricaricamento della configurazione di systemd manager2 | `systemctl daemon-reload` come root | scansione alla ricerca di unità nuove o modificate
Abilitazione di un'unità
Abilitazione di un'unità per l'avvio automatico al boot | `systemctl enable unità` come root |
Abilitazione di un'unità per l'avvio automatico al boot e suo avvio immediato | `systemctl enable --now unità` come root |
Disabilitazione di un'unità affinché non si avvi più al boot | `systemctl disable unità` come root |
Ri-abilitazione di un'unità3 | `systemctl reenable unità` come root | disabilitazione e nuova abilitazione
Mascheratura di un'unità
Mascheratura di un'unità per renderne impossibile l'avvio4 | `systemctl mask unità` come root |
Eliminazione della maschera da un'unità | `systemctl unmask unità` come root |

1. Vedere systemd.unit(5) § UNIT FILE LOAD PATH per informazioni sulle cartelle in cui sono contenuti i file unità.
2. Questo comando non chiede alle unità modificate di ricaricare le proprie configurazioni (vedere l'azione Ricaricamento).
3. Ad esempio nel caso la sezione `[Install]` dell'unità sia cambiata dopo la sua ultima abilitazione.
4. Sia manualmente che come dipendenza, motivo per cui la mascheratura risulta una pratica pericolosa. Verificare l'eventuale presenza di unità mascherate con il comando:

       $ systemctl list-unit-files --state=masked

### Gestione energetica

polkit è necessario per la gestione energetica come utente senza privilegi. Se ci si trova in una sessione utente systemd-logind locale e non è presente nessun'altra sessione attiva, i seguenti comandi funzioneranno senza privilegi. In caso contrario (ad esempio, poiché un altro utente ha eseguito il login in un tty), systemd richiederà automaticamente la password di root.

Azione | Comando
--- | ---
Arresto e reboot del sistema | `systemctl reboot`
Arresto e spegnimento del sistema | `systemctl poweroff`
Sospensione del sistema | `systemctl suspend`
Ibernazione del sistema (scrittura della ram su disco) | `systemctl hibernate`
Il sistema viene messo in uno stato ibrido di sospensione (noto anche come suspend-to-both, che salva la RAM sul disco per poi procedere alla sospensione) | `systemctl hybrid-sleep`
Prima sospende il sistema, dopodiché lo riattiva dopo un tempo configurato solo per poi ibernarlo | `systemctl suspend-then-hibernate`

## Scrittura dei file unità

La sintassi dei file unità systemd (systemd.unit(5)) è ispirata da quella dei XDG Desktop Entry Specification file .desktop i quali, a loro volta, si ispirano ai file . ini di Microsoft Windows. I file unità vengono caricati da diverse posizioni (per un elenco completo, eseguire `systemctl show --property=UnitPath`), ma le principali sono (riportate in ordine crescente di precedenza):

- `/usr/lib/systemd/system/`: unità fornite dai pacchetti installati
- `/etc/systemd/system/`: unità installate dall'amministratore di sistema

Nota:

- I percorsi di caricamento sono completamente diversi quando si esegue systemd in modalità utente.
- i nomi unità systemd possono contenere solo caratteri alfanumerici ASCII, underscore e punti. Tutti gli altri caratteri devono essere sostituiti da stringhe escape "\x2d" in stile C, o in alternativa è possibile utilizzare la rispettiva semantica predefinita ('@', '-'). Vedere systemd.unit(5) e systemd-escape(1) per maggiori informazioni.

Per visualizzare degli esempi, analizzare le unità installate dai pacchetti nel proprio sistema o vedere systemd.service(5) § EXAMPLES.

Suggerimento: È possibile utilizzare il carattere `#` per inserire commenti. Tuttavia è possibile commentare solo nuove linee. Non inserire commenti a fine linea dopo i parametri systemd o non sarà possibile attivare l'unità.

### Gestione delle dipendenze

Con systemd, le dipendenze possono essere risolte strutturando in modo corretto i file unità. Il caso più tipico è rappresentato dall'unità A che necessita che l'unità B sia in esecuzione prima che A possa essere avviata. 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 implicano `After=`. Ciò significa che se `After=` non viene specificato, le due unità verranno avviate in parallelo.

Le dipendenze vengono tipicamente definite nei servizi e non nei target. Ad esempio, `network.target` è richiamato da qualunque servizio si occupi della configurazione delle interfacce di rete, pertanto definire la propria unità personalizzata affinché si avvi dopo di esso è sufficiente, dal momento che `network.target` viene avviato in ogni caso.

### Tipi di servizi

Sono diverse le tipologie di avvio da considerare quando si scrive un file personalizzato per un servizio. La tipologia è definita dal parametro `Type=` nella sezione `[Service]`:

- `Type=simple` (default): systemd considera il servizio per l'avvio immediato. Il processo non deve essere eseguito come fork. Non utilizzare questa tipologia qualora altri servizi debbano essere ordinati sulla base di questo servizio, a meno che non sia attivato da un socket.
- `Type=forking`: systemd considera il servizio per l'avvio nel momento in cui il processo si avvia come fork e il processo parent viene terminato. A meno che non si sia certi che non risulta necessario, per i demoni classici utilizzare questa tipologia. È opportuno specificare anche `PIDFile=` in modo che systemd possa tenere traccia del processo principale.
- `Type=oneshot`: questa tipologia è utile per gli script che eseguono un singolo job per poi essere terminati. Può essere opportuno impostare anche `RemainAfterExit=yes`, in modo che systemd continui a considerare il servizio attivo anche dopo che è stato terminato. L'impostazione di `RemainAfterExit=yes` è appropriata per le unità che modificano lo stato del sistema (ad es., montaggio di una partizione).
- `Type=notify`: identico a `Type=simple`, ma con la condizione che il demone invierà un segnale a systemd quando è pronto. L'implementazione di riferimento per questa notifica è fornita da libsystemd-daemon.so.
- `Type=dbus`: il servizio è considerato pronto quando il `BusName` specificato compare nel bus di sistema di DBus.
- `Type=idle`: systemd ritarderà l'esecuzione del file binario del servizio fino a quando tutti i job sono stati avviati. A parte questo è molto simile a `Type=simple`.

Vedere la pagina del manuale systemd.service(5) § OPTIONS per una spiegazione più dettagliata dei valori `Type`.

### Modifica delle unità fornite

Per evitare conflitti con pacman, è opportuno evitare di modificare direttamente i file unità forniti dai pacchetti. Ci sono due modi per modificare in sicurezza un'unità senza intervenire sul file originale: creare un nuovo file unità che abbia la precedenza sull'unità originale o creare file drop-in che vengono applicati al di sopra dell'unità originale. Con entrambi i metodi è necessario ricaricare l'unità per applicare le modifiche apportate. Per farlo è possibile modificare l'unità con il comando `systemctl edit` (che ricarica l'unità automaticamente) o ricaricando tutte le unità con:

    # systemctl daemon-reload

Suggerimento:

- È possibile utilizzare systemd-delta per visualizzare quali file unità siano interessati da file con precedenza su di essi o da estensioni, e cosa sia effettivamente stato cambiato.
- Utilizzare `systemctl cat unità` per visualizzare il contenuto di un file unità e di tutti i file di drop-in associati.

#### File unità sostitutivi

Per sostituire il file unità `/usr/lib/systemd/system/unità`, creare il file `/etc/systemd/system/unità` e riabilitare l'unità per aggiornare i link simbolici.

In alternativa, eseguire:

    # systemctl edit --full unità

Questo comando apre il file `/etc/systemd/system/unità` nel proprio editor di testo (copiando la versione installata se non ancora esistente) e ricaricandola automaticamente una volta terminate le modifiche.

Nota: Le unità inserite in sostituzione di quelle originali continueranno a essere utilizzate in futuro anche nel caso in cui dette unità originali dovessero essere aggiornate da Pacman. Questo metodo rende più difficoltosa la manutenzione del sistema, pertanto è da preferirsi l'approccio successivo.

#### File di drop-in

Per creare file di drop in per il file unità `/usr/lib/systemd/system/unità`, creare la cartella `/etc/systemd/system/unità.d/` e inserirvi file con estensione .conf per sovrascrivere le opzioni del file unità originale o aggiungerne di nuove. systemd leggerà e applicherà il contenuto di questi file in modo prioritario rispetto all'unità originale.

Il modo più facile per adottare questo approccio è eseguendo il comando:

    # systemctl edit unità --drop-in=nome_drop_in

Questo comando apre il file `/etc/systemd/system/unit.d/nome_drop_in.conf` nel proprio editor di testo (creandolo se necessario) e ricarica automaticamente l'unità una volta terminate le modifiche. Omettendo l'opzione `--drop-in=`, systemd utilizzerà il nome file di default `override.conf` .

Nota:

- Rimane invariata la necessità di inserire la chiave nella sezione appropriata del file di override.
- Non tutte le chiavi possono essere sovrascritte mediante file di drop-in. Ad esempio, per modificare la chiave `Conflicts=` è necessaria la sostituzione del file unità originale.

#### Tornare alla versione fornita in origine

Per annullare ogni modifica applicata a un file unità utilizzando il comando `systemctl edit` eseguire:

    # systemctl revert unità

#### Esempi

Ad esempio, se si desidera semplicemente aggiungere una dipendenza opzionale a un'unità, è possibile creare il seguente file:

    /etc/systemd/system/unità.d/customdependency.conf

    [Unit]
    Requires=nuova dipendenza
    After=nuova dipendenza

A titolo di ulteriore esempio, per sostituire l'istruzione `ExecStart`, creare il seguente file:

    /etc/systemd/system/unità.d/customexec.conf

    [Service]
    ExecStart=
    ExecStart=nuovo comando

Notare come sia necessario azzerare `ExecStart` prima che sia possibile riassegnarvi un altro valore [1]. Lo stesso principio si applica a qualunque elemento che possa essere specificato più volte, ad es. `OnCalendar` per i timer.

Un ulteriore esempio per riavviare automaticamente un servizio:

    /etc/systemd/system/unità.d/restart.conf

    [Service]
    Restart=always
    RestartSec=30

## Target

systemd utilizza i target per raggruppare le unità per mezzo delle dipendenze e come punti di sincronizzazione standardizzati. La loro funzione è simile a quelle dei runlevel ma agiscono in modo leggermente diverso. A ciascun target è associato un nome anziché un numero e ognuno di essi è concepito per svolgere una specifica funzione con la possibilità di averne pi di uno attivo allo stesso tempo. Alcuni target sono implementati ereditando tutti i servizi di un altro target e aggiungendone di altri. Sono presenti dei "target" systemd riproducono i comuni runlevel SystemVinit in modo da consentire di passare da un "target" all'altro utilizzando il comando `telinit RUNLEVEL` familiare.

### Rilevare i target attualmente in uso

In systemd è preferibile utilizzare il seguente comando in luogo di `runlevel`:

    $ systemctl list-units --type=target

### Creazione di un target personalizzato

I runlevel che possedevano un significato definito in sysvinit (vale a dire 0, 1, 3, 5, e 6) possiedono una mappatura 1:1 con un "target" systemd specifico. Sfortunatamente non è disponibile alcuna soluzione ottimale per adottare il medesimo approccio per i runlevel definiti dall'utente quali 2 e 4. Nel caso si utilizzi uno di questi ultimi, si suggerisce di creare un "target" systemd con un nuovo nome come `/etc/systemd/system/proprio target` che prenda uno dei runlevel esistenti come base (è possibile visualizzare `/usr/lib/systemd/system/graphical.target` come esempio), creare una directory `/etc/systemd/system/proprio target.wants`, e inserirvi i link simbolici ai servizi aggiuntivi presenti in `/usr/lib/systemd/system/` che si desidera abilitare.

### Mappatura tra i runlevel SysV e i target systemd

Runlevel SysV | Target systemd | Note
--- | --- | ---
0 | runlevel0.target, poweroff.target | Arresta il sistema.
1, s, single | runlevel1.target, rescue.target | Modalità utente singolo.
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Runlevel definiti dall'utente/specifici per il sito. Per impostazione predefinita, identici a 3.
3 | runlevel3.target, multi-user.target | Multi-utente, non grafico. Gli utenti possono di norma effettuare il login tramite console multiple o via rete.
5 | runlevel5.target, graphical.target | Multi-utente, grafico. Di norma possiede tutti i servizi del runlevel 3 più un login grafico.
6 | runlevel6.target, reboot.target | Riavvio
emergency | emergency.target | Shell di emergenza

### Cambiare il target attualmente in uso

In systemd, i target vengono esposti mediante target unit. È possibile modificarli come segue:

    # systemctl isolate graphical.target

Questo comando si limiterà a cambiare il target attuale, senza alcun effetto sul boot successivo. Equivale a comandi quali `telinit 3` o `telinit 5` in Sysvinit.

### Modifica del target di default in cui effettuare il boot

Il target standard è `default.target`, che è un link simbolico a `graphical.target`. A grandi linee corrisponde al vecchio runlevel 5.

Per verificare il target attuale con systemctl:

    $ systemctl get-default

Per modificare il target di default in cui eseguire il boot modificare il link simbolico `default.target`. Con systemctl:

    # systemctl set-default multi-user.target

    Removed /etc/systemd/system/default.target.
    Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

In alternativa, aggiungere i seguenti parametri del kernel al proprio boot loader:

- `systemd.unit=multi-user.target` (che corrisponde a grandi linee al vecchio runlevel 3),
- `systemd.unit=rescue.target` (che corrisponde a grandi linee al vecchio runlevel 1).

### Ordine del target di default

systemd sceglie il `default.target` sulla base del seguente ordine di priorità:

1. Il parametro del kernel precedentemente indicato
2. Link simbolico di `/etc/systemd/system/default.target`
3. Link simbolico di `/usr/lib/systemd/system/default.target`

## Componenti di systemd

Alcuni componenti (elenco non esaustivo) di systemd sono:

- kernel-install — uno script utilizzato per spostare automaticamente i kernel e le rispettive immagini initramfs nella partizione di boot;
- systemd-boot — semplice boot boot manager UEFI;
- systemd-creds — per conservare in modo sicuro e recuperare le credenziali utilizzate dalle unità systemd;
- systemd-cryptenroll — registra i token/dispositivi PKCS#11, FIDO2, TPM2 nei volumi con cifratura LUKS2;
- systemd-firstboot — inizializzazione di base delle impostazioni di sistema prima del primo boot;
- systemd-homed — account utente umano portatili;
- systemd-logind(8) — gestione della sessione;
- systemd-networkd — gestione della configurazione di rete;
- systemd-nspawn — contenitore namespace leggero;
- systemd-resolved — risoluzione del nome di rete;
- systemd-stub(7) — uno stub per il boot UEFI utilizzato per la creazione di unified kernel image;
- systemd-sysusers(8) — crea gli utenti e i gruppi di sistema e aggiunge gli utenti ai gruppi in fase di installazione dei pacchetti o in fase di boot;
- systemd-timesyncd — sincronizzazione dell'ora di sistema all'interno della rete;
- systemd/Journal — creazione dei log di sistema;
- systemd/Timers — timer monotonici o in tempo reale per controllare file .service o eventi, alternativa ragionevole a cron.

### Montaggio systemd.mount

systemd è responsabile del montaggio delle partizioni e dei file system specificati in `/etc/fstab`. Il systemd-fstab-generator(8) traduce tutte le voci presenti in `/etc/fstab` in unità systemd; questa operazione viene eseguita al momento del boot e ogniqualvolta la configurazione del gestore di sistema viene ricaricata.

systemd estende le comuni funzionalità di fstab e offre ulteriori opzioni di montaggio. Queste opzioni hanno effetto sulle dipendenze dell'unità di montaggio. Ad esempio, assicurano che un montaggio sia eseguito solo dopo che la rete è attiva o solo quando un'altra partizione è stata a sua volta montata. L'elenco specifico delle opzioni di montaggio di systemd, che tipicamente si presentano con prefisso `x-systemd.`, è riportato in dettaglio in systemd.mount(5) § FSTAB.

Un esempio di queste opzioni di montaggio è automounting, che fa sì che il montaggio venga effettuato solo quando la risorsa viene richiesta anziché al boot. Questa opzione è descritta inoltre alla pagina fstab.

#### Montaggio automatico di una partizione GPT

Nei sistemi avviati in modalità UEFI, nel caso vengano soddisfatte determinate condizioni, systemd-gpt-auto-generator(8) eseguirà il montaggio automatico delle partizioni GPT seguendo le specifiche sulle partizioni individuabili. Le partizioni montate automaticamente possono pertanto essere omesse da fstab, e se la partizione root è montata automaticamente, sarà possibile omettere `root=` dalla linea di comando del kernel.

I prerequisiti sono:

- Il boot loader deve impostare la variabile EFI LoaderDevicePartUUID, in modo tale da consentire l'identificazione della partizione di sistema EFI. Questa funzione è supportata da systemd-boot, systemd-stub(7), GRUB (`grub.cfg` generato con grub-mkconfig; un eventuale `grub.cfg` personalizzato richiede il caricamento del modulo bli) e rEFInd (non abilitata di default). La presenza di questa condizione può essere verificata eseguendo `bootctl` e controllando lo stato di `Boot loader sets ESP information` o lo stato di `Stub sets ESP information` quando si esegue il boot via Unified kernel image.
- La partizione di root deve essere sul medesimo disco fisico della partizione di sistema EFI. Le altre partizioni che verranno montate automaticamente devono essere sul medesimo disco fisico della partizione di root. Ciò significa quindi che tutte le partizioni montate automaticamente devono essere sul medesimo disco fisso della partizione ESP.
- Il punto di montaggio `/efi` deve essere creato manualmente (se lo si desidera), in caso contrario `systemd-gpt-auto-generator` utilizzerà `/boot`.

Attenzione: Prestare la massima attenzione nel creare `/efi` in un sistema esistente quando si utilizza il montaggio automatico GPT. `/efi` verrà usato come punto di montaggio di default al boot successivo, e questo potrebbe lasciare il proprio sistema in uno stato incongruente con una directory `/boot` vuota. Con ogni probabilità sarà necessario re-installare il proprio o i propri kernel e/o il microcode, rigenerare la propria immagine initramfs, ecc..
Suggerimento: Il montaggio automatico di una partizione può essere disabilitato modificando il tipo GUID della partizione o impostando il bit 63 dell'attributo della partizione su "do not automount", vedere gdisk#Prevent GPT partition automounting.

##### /var

Affinché il montaggio automatico di `/var` funzioni, il PARTUUID deve corrispondere all'hash HMAC SHA256 dell'UUID del tipo di partizione (`4d21b016-b534-45c2-a9fb-5c16e091fd2d`) come da chiave dell'ID macchina. Il necessario PARTUUID può essere ottenuto utilizzando:

    $ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

Nota: systemd-id128(1) legge l'ID macchina da `/etc/machine-id`, rendendo pertanto impossibile sapere il necessario PARTUUID prima che il sistema sia installato.

### systemd-sysvcompat

Il ruolo principale di systemd-sysvcompat (richiesto da base) è di fornire il file binario init tradizionale di linux. Per i sistemi controllati da systemd, `init` è semplicemente un link simbolico al rispettivo eseguibile `systemd`.

Inoltre fornisce quattro pratiche scorciatoie alle quali gli utenti SysVinit potrebbero essere abituati. Queste pratiche scorciatoie sono halt(8), poweroff(8), reboot(8) e shutdown(8). Ciascuno di questi comandi è un link simbolico a `systemctl`, ed è governato dal comportamento di systemd. Pertanto si applica quanto discusso in #Gestione energetica.

I sistemi basati su systemd possono rinunciare a questi metodi di compatibilità con System V utilizzando il parametro di boot `init=` (vedere, ad esempio, /bin/init is in systemd-sysvcompat ?) e gli argomenti di comando `systemctl` nativi di systemd.

### systemd-tmpfiles - file temporanei

systemd-tmpfiles crea, cancella e pulisce i file e le directory temporanei e volatili. Legge i file di configurazione in `/etc/tmpfiles.d/` e `/usr/lib/tmpfiles.d/` per individuare le azioni da eseguire. I file di configurazione nella prima directory hanno precedenza su quelli nella seconda.

I file di configurazione sono di norma forniti unitamente ai file dei relativi servizi, e il loro nome segue di norma questo schema `/usr/lib/tmpfiles.d/programma.conf`. Ad esempio, il demone Samba richiede che la directory `/run/samba` sia presente e configurata con i permessi corretti. Pertanto, il pacchetto samba viene fornito con la seguente configurazione:

    /usr/lib/tmpfiles.d/samba.conf

    D /run/samba 0755 root root

I file di configurazione possono anche essere utilizzati per scrivere valori all'interno di determinati file al boot. Ad esempio, nel caso si sia fatto ricorso a `/etc/rc.local` per disabilitare il wakeup da dispositivi USB con `echo USBE > /proc/acpi/wakeup` è possibile, come alternativa, utilizzare il seguente tmpfile:

    /etc/tmpfiles.d/disable-usb-wake.conf

    #    Path                  Mode UID  GID  Age Argument
    w    /proc/acpi/wakeup     -    -    -    -   USBE

Vedere le pagine del manuale systemd-tmpfiles(8) e tmpfiles.d(5) per maggiori dettagli.

Nota: Questo metodo potrebbe non funzionare per impostare opzioni in `/sys` dal momento che il servizio systemd-tmpfiles-setup potrebbe essere eseguito prima che i rispettivi moduli del dispositivo siano stati caricati. In questo caso, è possibile verificare se il modulo possieda un parametro per l'opzione che si desidera impostare con `modinfo modulo` e impostare questa opzione con un file di configurazione in /etc/modprobe.d. In caso contrario sarà necessario scrivere una regola udev per impostare l'attributo appropriato non appena il dispositivo compare.

## Trucchi e suggerimenti

This article or section needs expansion.

Reason: Sarebbe opportuno documentare in modo esplicito in qualche punto i benefici dell'attivazione del socket rispetto al semplice avvio del servizio. Questo aspetto è menzionato in breve all'inizio della presente pagina e in pagine correlate quali Avahi. (Discuss in Talk:Systemd (Italiano))

### Strumenti GUI di configurazione

- systemadm — Browser grafico per le unità systemd. Permette di visualizzare l'elenco delle unità, eventualmente filtrate per tipo.

  https://cgit.freedesktop.org/systemd/systemd-ui/ || systemd-ui

- SystemdGenie — Strumento di gestione di systemd basato su tecnologie KDE.

  https://invent.kde.org/system/systemdgenie || systemdgenie

### Esecuzione di servizi dopo l'attivazione della rete

Per ritardare l'esecuzione di un servizio fino al momento in cui la rete è attiva, includere le seguenti dipendenze nel file .service:

    /etc/systemd/system/foo.service

    [Unit]
    ...
    Wants=network-online.target
    After=network-online.target
    ...

È inoltre necessario abilitare il servizio di attesa della rete del gestore di rete in uso in modo tale che `network-online.target` rifletta in modo appropriato lo stato della rete.

- Se si utilizza NetworkManager, `NetworkManager-wait-online.service` andrebbe abilitato unitamente a `NetworkManager.service`. Verificare l'avvenuta attivazione con il comando `systemctl is-enabled NetworkManager-wait-online.service`. In caso contrario, riabilitare `NetworkManager.service`.
- Nel caso di netctl, abilitare il servizio `netctl-wait-online.service` (a meno che non si utilizzi netctl-auto; vedere FS#75836).
- Se si utilizza systemd-networkd, `systemd-networkd-wait-online.service` andrebbe abilitato unitamente a `systemd-networkd.service`. Verificare l'avvenuta attivazione con il comando `systemctl is-enabled systemd-networkd-wait-online.service`. In caso contrario, riabilitare `systemd-networkd.service`.

Per spiegazioni maggiormente dettagliate, vedere la discussione nella pagina relativa ai punti di sincronizzazione della configurazione di rete.

Se un servizio necessita di effettuare delle query DNS, andrebbe inoltre eseguito dopo `nss-lookup.target`:

    /etc/systemd/system/foo.service

    [Unit]
    ...
    Wants=network-online.target
    After=network-online.target nss-lookup.target
    ...

Vedere systemd.special(7) § unità di sistema speciali passive.

Per avere effetto, `nss-lookup.target` necessita di un servizio che lo richiami tramite `Wants=nss-lookup.target` e che si ponga prima di esso nell'ordine di esecuzione con `Before=nss-lookup.target`. Tipicamente questa funzione viene svolta dai DNS resolver locali.

Per controllare quale servizio attivo, se presente, richiami `nss-lookup.target` eseguire il comando:

    $ systemctl list-dependencies --reverse nss-lookup.target

### Abilitazione delle unità installate come impostazione predefinita

This article or section needs expansion.

Reason: Come funziona con le unità istanziate? (Discuss in Talk:Systemd (Italiano))

Arch Linux viene fornito con `/usr/lib/systemd/system-preset/99-default.preset` contenente `disable *`. Ciò fa sì che systemctl preset disabiliti tutte le unità per impostazione predefinita. Di conseguenza, quando viene installato un nuovo pacchetto, deve essere l'utente ad abilitare manualmente l'unità.

Qualora si desideri modificare questo comportamento, è sufficiente creare un link simbolico da `/etc/systemd/system-preset/99-default.preset` a `/dev/null` per inibire l'azione del file di configurazione. Ciò farà sì che systemctl preset abiliti tutte le unità che vengono installate, indipendentemente dal loro tipo, a meno che non sia diversamente specificato in un altro file in una delle directory di configurazione di systemctl preset. Le unità utente non sono interessate. Vedere systemd.preset(5) per maggiori informazioni.

Nota: L'abilitazione di tutte le unità per impostazione predefinita può causare problemi con i pacchetti contenenti due o più unità che si escludono reciprocamente. systemctl preset è progettato per essere utilizzato da distribuzioni e spin o da amministratori di sistema. Nei casi in cui verrebbero abilitate due unità in conflitto l'una con l'altra, è opportuno specificare esplicitamente quale delle due debba essere disabilitata in un file di configurazione di preset, come specificato nella pagina del manuale systemd.preset(5).

### Sandboxing degli ambienti applicazione

This article or section is a candidate for moving to systemd/Sandboxing.

Notes: L'ampiezza dell'argomento è sufficiente per una pagina dedicata. Vedere User:NetSysFire/systemd sandboxing per una proposta di bozza. (Discuss in Talk:Security#systemd unit hardening and system.conf tweaks)

È possibile creare un file unità come sandbox al fine di isolare le applicazioni e i relativi processi all'interno di un ambiente virtuale rinforzato. systemd sfrutta i namespace, un elenco di capability e gruppi di controllo consentiti/proibiti per i processi dei contenitori, per mezzo di una configurazione estesa dell'ambiente di esecuzione systemd.exec(5).

L'ottimizzazione di un file unità systemd esistente con il sandboxing dell'applicazione necessita tipicamente di un processo di apprendimento per tentativi ed errori, accompagnato da un uso intensivo di strace, stderr, logging degli errori in journalctl(1), e lettura degli output. È consigliabile dapprima effettuare una ricerca nella documentazione upstream per verificare l'esistenza di test già effettuati sui quali basare i propri tentativi. Per ottenere un punto di partenza per le possibili opzioni di rafforzamento, eseguire

    $ systemd-analyze security unità

Alcuni esempi sulle modalità di implementazione del sandboxing con systemd:

- `CapabilityBoundingSet` definisce un elenco di capabilities(7) consentite o proibite per un'unità. Vedere systemd.exec(5) § CAPABILITIES.
  - La capability `CAP_SYS_ADM`, ad esempio, che dovrebbe essere uno degli obiettivi di un sandbox sicuro: `CapabilityBoundingSet=~ CAP_SYS_ADM`

### Notifiche di fallimento dei servizi

This article or section is a candidate for merging with systemd/Timers#MAILTO.

Notes: Stesso argomento, diversa soluzione. (Discuss in Talk:Systemd (Italiano))

Per consentire l'invio di notifiche sui fallimenti dei servizi, è necessario aggiungere una direttiva `OnFailure=` ai rispettivi file servizio, ad esempio utilizzando un file di drop-in di configurazione. È possibile aggiungere questa direttiva a ogni unità servizio con un file di drop-in di configurazione di livello top. Per maggior dettagli sui file di drop-in di livello top, vedere systemd.unit(5).

Creare un file di drop-in di livello top per i servizi:

    /etc/systemd/system/service.d/toplevel-override.conf

    [Unit]
    OnFailure=failure-notification@%n

In questo modo viene aggiunto `OnFailure=failure-notification@%n` a ogni file servizio. Se si verifica il fallimento di una_unità_servizio, verrà avviato `failure-notification@una_unità_servizio` per gestire la consegna della notifica (o qualunque compito sia configurato per eseguire).

Creare l'unità modello `failure-notification@`:

    /etc/systemd/system/failure-notification@.service

    [Unit]
    Description=Send a notification about a failed systemd unit
    After=network.target

    [Service]
    Type=simple
    ExecStart=/percorso/a/failure-notification.sh %i

È possibile creare lo script `failure-notification.sh` e definire le azioni da eseguire o la modalità di invio delle notifiche (mail, gotify, xmpp, ecc.). `%i` sarà il nome dell'unità di servizio interessata dal fallimento che verrà passato come argomento allo script.

Al fine di prevenire la ricorsività delle istanze in avvio di `failure-notification@.service` in caso di fallimento dell'avvio, creare un file di drop-in di configurazione vuoto con il medesimo nome del file di drop-in di livello top (il file di configurazione vuoto a livello di servizio ha precedenza rispetto a quello di livello top inibendone l'azione):

    # mkdir -p /etc/systemd/system/failure-notification@.service.d
    # touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

### Spegnimento automatico di un hard disk esterno all'arresto

This article or section is a candidate for merging with Udisks#Troubleshooting.

Notes: Questa voce si concentra principalmente sull'utilizzo di udisks, pertanto è probabilmente più adatta per questo contenuto rispetto alla pagina di systemd. (Discuss in Talk:Systemd (Italiano))

Se un hard disk esterno non viene correttamente spento al momento dell'arresto del sistema, potrebbe risultare opportuno risolvere questo problema. La soluzione più pratica è utilizzare a tal fine udisks.

Abilitare `udisks2.service`.

Un servizio che invochi il nostro script potrebbe essere:

    /etc/systemd/system/handle_external_hdds.service

    [Unit]
    Requires=udisks2.service
    Requires=graphical.target
    After=graphical.target
    [Service]
    Type=oneshot
    RemainAfterExit=yes
    ExecStop=/usr/local/bin/handle_external_hdds.sh
    [Install]
    WantedBy=graphical.target

Abilitare `handle_external_hdds.service`

Ricaricare il demone di systemd per applicare la nuova impostazione.

Eseguire il reboot o riavviare `graphical.target` per verificare il corretto funzionamento.

Un esempio di script per gestire un numero arbitrario di partizioni su un singolo disco:

    /usr/local/bin/handle_external_hdds.sh

    #!/bin/bash -u

    declare -a uuids=(uuid_list)

    # Only proceed if the drive is present.
    if [[ ! -L "/dev/disk/by-uuid/${uuids[0]}" ]]; then
      exit 0
    fi

    for uuid in "${uuids[@]}"; do
      if findmnt "/dev/disk/by-uuid/$uuid"; then
        umount "/dev/disk/by-uuid/$uuid"
      fi
    done

    # udisksctl powers off proper drive even if its partition is supplied
    udisksctl power-off -b "/dev/disk/by-uuid/${uuids[0]}"

uuid_list è un elenco di UUID delimitati da spazi, corrispondenti alle partizioni del dispositivo da verificare, ad es. `"uuid_1" "uuid_2"`.

## Risoluzione di problemi

### Indagare sui servizi falliti

Per individuare quali servizi systemd non si siano avviati eseguire:

    $ systemctl --state=failed

Per scoprire il motivo del mancato avvio, esaminare il rispettivo output di log. Vedere systemd/Journal#Filtering output per maggiori dettagli.

### Diagnosi dei problemi di boot

systemd offre diverse opzioni per la diagnosi dei problemi che interessano in processo di boot. Vedere boot debugging per istruzioni più generali e opzioni per catturare i messaggi di boot prima che systemd prenda il controllo del processo di boot. Vedere anche freedesktop.org's documentazione di debug di systemd.

### Diagnosi di un servizio

Se un servizio systemd mostra un comportamento non conforme o se si desidera ottenere maggiori informazioni su cosa si sta verificando, impostare la variabile d'ambiente `SYSTEMD_LOG_LEVEL` su `debug`. Ad esempio, per eseguire il demone systemd-networkd in modalità di debug:

Aggiungere un file di drop-in per il servizio inserendo le seguenti due linee:

    [Service]
    Environment=SYSTEMD_LOG_LEVEL=debug

Oppure, in modo equivalente, impostare manualmente la variabile d'ambiente:

    # SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

dopodiché riavviare systemd-networkd e visualizzare il journal relativo al servizio con l'opzione `-f`/`--follow`.

### Lo spegnimento/il riavvio impiega un tempo eccessivamente lungo

Se il processo di spegnimento richiede un tempo particolarmente lungo (o sembra bloccarsi), con ogni probabilità ciò è da attribuirsi a un servizio che non si arresta. systemd attende per un po' di tempo prima di tentare di forzarne l'arresto. Per verificare se si è interessati da questo problema, vedere Shutdown completes eventually nella wiki di systemd.

Un problema comune è uno spegnimento in stallo o un processo di sospensione. È possibile eseguire entrambi i seguenti comandi e analizzare il rispettivo output per accertarsi della presenza di questo problema

    # systemctl poweroff

    Failed to power off system via logind: There's already a shutdown or sleep operation in progress

    # systemctl list-jobs

      JOB UNIT                    TYPE  STATE
    ...
    21593 systemd-suspend.service start running
    21592 suspend.target          start waiting
    ..

La soluzione a questo problema è annullare questi processi eseguendo

    # systemctl cancel
    # systemctl stop systemd-suspend.service

dopodiché provare a eseguire nuovamente lo spegnimento o il riavvio.

### I processi con breve tempo di esecuzione non registrano alcun output nel log

Se l'esecuzione di `journalctl -u foounit` come utente root non mostra alcun output per un servizio con breve tempo di esecuzione, provare con il PID. Ad esempio, se `systemd-modules-load.service` fallisce, e `systemctl status systemd-modules-load` indica che è stato eseguito come PID 123, potrebbe essere possibile visualizzare l'output nel journal per questo PID, ad es. eseguendo `journalctl -b _PID=123` come utente root. I campi dei metadati per il journal quali `_SYSTEMD_UNIT` e `_COMM` sono rilevati in modo asincrono e fanno affidamento sull'esistenza della directory `/proc` per il processo. La risoluzione di questo problema richiede di intervenire sul kernel per far sì che questi dati vengano forniti mediante connessione socket, similmente a `SCM_CREDENTIALS`. In breve, si tratta di un bug. Tenere in considerazione che, per scelta progettuale di systemd, i servizi che falliscono immediatamente potrebbero non generare alcun output nel journal.

### Il tempo di boot aumenta nel tempo

The factual accuracy of this article or section is disputed.

Reason: I problemi legati a NetworkManager sono sono da attribuirsi a systemd, le testimonianze a cui si fa riferimento sono mancanti. La lentezza di `systemctl status` o `journalctl` non ha alcun effetto sul tempo di boot. (Discuss in Talk:Systemd (Italiano))

Dopo aver usato `systemd-analyze` un numero elevato di utenti ha notato un aumento significativo del proprio tempo di boot rispetto al passato. L'utilizzo di `systemd-analyze blame` ha mostrato come NetworkManager impieghi un tempo insolitamente lungo per l'avvio.

Il problema, per alcuni utenti, era dovuto alle dimensioni eccessive raggiunte dal file `/var/log/journal`. Ciò potrebbe incidere anche sulle prestazioni ad esempio di `systemctl status` o `journalctl`. Pertanto la soluzione è rimuovere ogni file dalla cartella (idealmente effettuandone prima un backup, almeno come accorgimento temporaneo) per poi impostare un limite per le dimensioni del file del journal come descritto in Systemd/Journal#Journal size limit.

### systemd-tmpfiles-setup.service non si avvia al boot

A partire dalla versione 219 di systemd, `/usr/lib/tmpfiles.d/systemd.conf` specifica gli attributi ACL per le directory in `/var/log/journal` e, pertanto, richiede l'abilitazione del supporto ACL per il file system che ospita il journal.

Vedere Access Control Lists#Enable ACL per le istruzioni su come abilitare ACL nel file system su cui è salvato `/var/log/journal`.

### Disabilitazione delle modalità di emergenza sulla macchina remota

Si potrebbe desiderare disabilitare la modalità di emergenza in una macchina remota, ad esempio una macchina virtuale con hosting su Azure o Google Cloud. Questo in quanto, se viene attivata la modalità di emergenza, ciò impedirà alla macchina di connettersi alla rete.

Per disabilitare questa modalità mascherare `emergency.service` e `emergency.target`.

## Vedere anche

- Wikipedia:systemd
- Sito web ufficiale
  - Ottimizzazioni di systemd
  - FAQ su systemd
  - Trucchi e suggerimenti su systemd
- systemd(1)
- Altre distribuzioni
  - Gentoo:Systemd
  - Fedora:Systemd
  - Fedora:How to debug Systemd problems
  - Fedora:SysVinit to Systemd Cheatsheet
  - Debian:systemd
- Storia del blog di Lennart, aggiornamento 1, aggiornamento 2, aggiornamento 3, sommario
- Debug dei servizi di systemd
- systemd per amministratori (PDF)
- Come utilizzare systemctl per gestire i servizi e le unità systemd
- Gestione della sessione con systemd-logind
- Emacs#Syntax highlighting for systemd files
- Articolo introduttivo in due parti sul magazine The H Open.

Category:

- Init (Italiano)

Hidden categories:

- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Move
- Pages or sections flagged with Template:Merge
- Pages or sections flagged with Template:Accuracy