systemd (Italiano)

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
/Timers
/Journal
Systemd/Sandboxing
/Domande frequenti
init
udev
Migliorare le performance/Processo di avvio
Permettere agli utenti di spegnere
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 l
utente che effettua la chiamata
), utilizzare
systemctl --user
senza privilegi di root. Vedere anche
Systemd/User#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à.
Quando è disponibile, potrebbe essere meglio abilitare
unit
.socket
invece di
unit
.service
perché il socket avvia il servizio solo quando necessario. Si veda
#Attivazione del socket
per maggiori dettagli.
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à
installati
1
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
Ricaricamento
di un'unità e della relativa configurazione
systemctl reload
unità
come root
Ricaricamento
della configurazione di
systemd manager
2
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'avvio
4
systemctl mask
unità
come root
Eliminazione della maschera
da un'unità
systemctl unmask
unità
come root
Vedere
systemd.unit(5) § UNIT FILE LOAD PATH
per informazioni sulle cartelle in cui sono contenuti i file unità.
Questo comando non chiede alle unità modificate di ricaricare le proprie configurazioni (vedere l'azione
Ricaricamento
).
Ad esempio nel caso la sezione
[Install]
dell'unità sia cambiata dopo la sua ultima abilitazione.
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
Soft reboot
Il soft reboot è un tipo particolare di operazione di riavvio limitata esclusivamente allo userspace, che non coinvolge il kernel. È implementato da
systemd-soft-reboot.service(8)
e può essere invocato tramite
systemctl soft-reboot
. Analogamente a
kexec
, questa procedura evita la reinizializzazione del firmware ma, in aggiunta, il sistema non attraversa le fasi di inizializzazione del kernel e dell'
initramfs
, e i dispositivi
dm-crypt
sbloccati rimangono collegati.
Quando
/run/nextroot/
contiene una gerarchia di file system root valida (ad esempio, il punto di montaggio root di un'altra distribuzione o di un altro snapshot), il
soft-reboot
commuta la root del sistema al suo interno. Ciò permette di passare a un'altra installazione senza perdere gli stati gestiti dal kernel, come ad esempio la
configurazione di rete
.
Suggerimento
/run/nextroot/
non è necessariamente un punto di montaggio o supportato da un dispositivo fisico. Ad esempio, può risiedere nel tmpfs di
/run/
. Durante un soft-reboot,
systemd
trasformerà automaticamente
/run/nextroot/
in un punto di montaggio.
Nota
Non invocare mai
systemctl soft-reboot
dopo un aggiornamento che coinvolga il kernel e initramfs.
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à.
systemd-analyze(1)
può essere d'aiuto nel verificare il lavoro svolto. Si legga la sezione
systemd-analyze verify FILE...
in quella pagina.
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
: questo è utile per script che eseguono un singolo compito e poi terminano. Potrebbe essere opportuno impostare anche
RemainAfterExit=yes
affinché
systemd
consideri il servizio ancora attivo dopo la conclusione del processo. L'impostazione
RemainAfterExit=yes
è indicata per le unità che modificano lo stato del sistema (ad esempio, il montaggio di una partizione). Si veda anche
[1]
per le differenze tra simple e oneshot.
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
This article or section needs expansion.
Reason:
Si dovrebbe aggiungere: "Se viene specificato
--runtime
, le modifiche verranno apportate temporaneamente in
/run/
e andranno perse al riavvio successivo.". Un esempio potrebbe essere il passaggio di flag di debug a un servizio senza voler mantenere le modifiche in modo permanente. (Discuss in
Talk:Systemd (Italiano)
)
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.
È possibile utilizzare file drop-in di primo livello per influenzare tutte le unità dello stesso tipo. Ad esempio, un file drop-in in
/etc/systemd/system/service.d/
ha effetto su tutte le unità
.service
. È possibile consultare un esempio in
#Notifiche di fallimento dei servizi
.
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
[2]
. 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
Livelli di log dei servizi
Per i servizi che inviano i log direttamente a journald o a syslog, è possibile controllarne la verbosità impostando un valore numerico compreso tra 0 e 6 per il parametro
LogLevelMax=
nella sezione
[Service]
, utilizzando i metodi sopra descritti. Ad esempio:
/etc/systemd/system/
unit
.d/override.conf
[Service]
LogLevelMax=3
I livelli di log standard sono identici a quelli utilizzati per filtrare il
journal
. L'impostazione di un numero inferiore esclude dal journal tutti i messaggi di log con valore superiore e meno importanti.
Soppressione dello standard output di un servizio
Se un servizio emette messaggi tramite stdout o stderr, per impostazione predefinita anche questi confluiranno nel journal. Questo comportamento può essere soppresso impostando
StandardOutput=null
e
StandardError=null
nella sezione
[Service]
. È possibile utilizzare valori diversi da
null
per perfezionare ulteriormente questo comportamento. Si veda
systemd.exec(5) § LOGGING_AND_STANDARD_INPUT/OUTPUT
.
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. Esistono dei
systemd targets
che imitano i comuni runlevel di SystemVinit.
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à:
Il parametro del kernel precedentemente indicato
Link simbolico di
/etc/systemd/system/default.target
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-analyze(1)
— può essere utilizzato per determinare le prestazioni e le statistiche dell'avvio, recuperare altre informazioni sullo stato e sul tracciamento, e verificare la correttezza dei file unit. Viene inoltre utilizzato per accedere a funzioni speciali utili per il debugging avanzato;
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-repart
— crea tabelle delle partizioni, aggiunge estende partizioni;
systemd-resolved
—
risoluzione del nome
di rete;
systemd-run(1)
/
run0
— Acquisisce temporaneamente e in modalità interattiva privilegi elevati o differenti;
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
Sui sistemi avviati tramite UEFI, le partizioni GPT come
root
,
home
,
swap
, ecc. possono essere montate automaticamente seguendo la
Discoverable Partitions Specification
. Queste partizioni possono quindi essere omesse da
fstab
e, se la partizione root viene montata automaticamente, il parametro
root=
può essere omesso dalla riga di comando del kernel. Si veda
systemd-gpt-auto-generator(8)
.
I prerequisiti sono:
Quando si utilizza
mkinitcpio
, l'
hook systemd
è necessario per montare automaticamente la partizione root.
Tutte le partizioni montate automaticamente devono risiedere sullo stesso disco fisico dell'ESP.
Devono essere impostati i tipi di partizione GPT corretti. Vedere
Partitioning (Italiano)#Schema di partizionamento
.
Il boot loader deve impostare la variabile EFI
LoaderDevicePartUUID
, in modo che la partizione di sistema EFI utilizzata possa essere identificata. Questo è supportato da
Systemd-boot
,
systemd-stub(7)
,
Limine
,
GRUB
(con
grub.cfg
generato da
grub-mkconfig
; un
grub.cfg
personalizzato richiede il
caricamento del modulo bli
) e
rEFInd (non abilitato per impostazione predefinita)
. Ciò può essere verificato eseguendo
bootctl
e controllando se è presente una riga con
Partition:
sotto
Current Boot Loader
o
Current Stub
quando si avvia tramite
Unified kernel images
.
udev
creerà
collegamenti simbolici alle partizioni rilevate
, che possono essere utilizzati per fare riferimento a partizioni e volumi nei file di configurazione.
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
GPT fdisk#Disabilitare il montaggio automatico di una partizione GPT
.
/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.
File di configurazione drop-in
The factual accuracy of this article or section is disputed.
Reason:
Questa pagina riguarda il PID 1 (init) e i drop-in delle unità sono già stati menzionati. Il concetto di drop-in è generico, inoltre altri componenti di systemd hanno le proprie pagine wiki dedicate. Pertanto, questa sezione non sembra appartenere a questo ambito. Discussione aperta in
Talk:Systemd#YHNdnzj_:_Configuration_files_in_conf.d_/_drop-in_snippets:_misplaced?
(Discuss in
Talk:Systemd (Italiano)
)
I file di configurazione forniti dai pacchetti non dovrebbero essere modificati direttamente per evitare conflitti con gli aggiornamenti di pacman. Per questo motivo, molti pacchetti systemd (ma non tutti) forniscono un modo per modificare la configurazione senza toccare il file originale, tramite la creazione di frammenti (snippet) drop-in. Consultare il manuale del pacchetto per verificare se i file di configurazione drop-in sono supportati.
Per creare un file di configurazione drop-in per il file unit
/etc/systemd/unit.conf
, creare la directory
/etc/systemd/unit.conf.d/
e inserire lì i file
.conf
per sovrascrivere o aggiungere nuove opzioni.
systemd
analizzerà e applicherà questi file al di sopra dell'unità originale.
Verificare la configurazione complessiva:
$ systemd-analyze cat-config systemd/unit.conf
I file dei frammenti drop-in applicati e il relativo contenuto saranno elencati alla fine.
Riavviare
il servizio affinché le modifiche abbiano effetto.
Trucchi e suggerimenti
Attivazione del socket
Alcuni pacchetti forniscono un'unità
.socket
. Per esempio,
cups
fornisce un'unità
cups.socket
[3]
.Quando si
abilita
cups.socket
(e si lascia disabilitato
cups.service
),
systemd
non avvierà subito CUPS, ma rimarrà in ascolto dei vari socket. Quando un programma tenta di collegarsi a uno di questi socket di CUPS,
systemd
avvierà
cups.service
e lascerà il controllo di queste porte in modo trasparente al processo CUPS.
Strumenti GUI di configurazione
systemadm
— Browser grafico per le unità
systemd
. Permette di visualizzare l'elenco delle unità, eventualmente filtrate per tipo.
https://github.com/systemd/systemd-ui
||
systemd-ui
SystemdGenie
— Strumento di gestione di
systemd
basato su tecnologie KDE.
https://apps.kde.org/systemdgenie/
||
systemdgenie
isd
— TUI per la gestione delle unità
systemd
https://github.com/kainctl/isd
||
isd
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)
)
Per impostazione predefinita, Arch Linux non utilizza i preset di systemd e non abilita la maggior parte dei servizi al momento dell'installazione.
Se si desidera che i preset di systemd vengano rispettati durante l'installazione dei pacchetti, sarà necessario creare un
hook di pacman
per eseguire
systemctl preset
o
systemctl preset-all
ogni volta che viene installata una nuova unità di systemd. Qualcosa come:
/etc/pacman.d/hooks/40-systemd-presets.hook
[Trigger]
Operation = Install
Type = Path
Target = usr/lib/systemd/system/*.service
Target = usr/lib/systemd/system/*.timer
Target = usr/lib/systemd/system/*.socket
Target = usr/lib/systemd/system/*.slice
Target = usr/lib/systemd/system/*.path
Target = usr/lib/systemd/system/*.target

[Action]
Description = Run systemctl preset
When = PostTransaction
Depends = systemd
NeedsTargets
# Alternatively, you could just run systemd preset-all.
# However, note that this will reset ALL services to the defaults,
# which is probably not what you want unless you have carefully configured
# your presets.
Exec = /etc/pacman.d/scripts/systemd-presets-hook
/etc/pacman.d/scripts/systemd-presets-hook
#!/bin/sh -e

while read -r f; do
    unit="${f##*/}"
    # alternatively, you could read all the units and pass them to systemctl preset in a single invocation
    systemctl preset "$unit"
done
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
Si veda
systemd/Sandboxing
.
Notifiche di fallimento dei servizi
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.service
In questo modo viene aggiunto
OnFailure=failure-notification@%n.service
a ogni file servizio. Se si verifica il fallimento di
una_unità_servizio
, verrà avviato
failure-notification@
una_unità_servizio
.service
per gestire la consegna della notifica (o qualunque compito sia configurato per eseguire).
Creare l'unità modello
failure-notification@.service
:
/etc/systemd/system/failure-notification@.service
[Unit]
Description=Send a notification about a failed systemd unit

[Service]
Type=oneshot
ExecStart=/
percorso
/
a
/failure-notification.sh %i
# runs as a temporary user/group and enables several other security precautions
DynamicUser=true
È possibile creare lo script
failure-notification.sh
e definire le azioni da eseguire o la modalità di invio delle notifiche. Ad esempio, è possibile
inviare email
,
mostrare notifiche desktop
, usare 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 /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf
Inviare notifiche via email
È possibile configurare systemd affinché invii un'e-mail quando un'unità fallisce. Cron invia e-mail a MAILTO se il processo produce output su stdout o stderr, ma molti processi sono configurati per produrre output solo in caso di errore. Per prima cosa sono necessari due file: un eseguibile per l'invio dell'e-mail e un file .service per avviare l'eseguibile. In questo esempio, l'eseguibile è semplicemente uno script di shell che utilizza
sendmail
, presente nei pacchetti che forniscono un
smtp-forwarder
.
/usr/local/bin/systemd-email
#!/bin/sh

/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL
Qualunque sia l'eseguibile utilizzato, dovrebbe probabilmente accettare almeno due argomenti, come fa questo script di shell: l'indirizzo a cui inviare l'e-mail e il file dell'unità di cui ottenere lo stato. Il file
.service
che creeremo passerà questi argomenti:
/etc/systemd/system/status_email_
user
@.service
[Unit]
Description=status email for %i to
user
[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email
address
%i
User=nobody
Group=systemd-journal
dove
user
è l'utente a cui viene inviata l'e-mail e
address
è l'indirizzo e-mail di quell'utente. Sebbene il destinatario sia codificato, il file dell'unità da segnalare viene passato come parametro di istanza, quindi questo singolo servizio può inviare e-mail per molte altre unità. A questo punto è possibile
avviare
status_email_user@dbus.service
per verificare di poter ricevere le e-mail.
Quindi, è sufficiente
modificare
il servizio per cui si desiderano le e-mail e aggiungere
OnFailure=status_email_
user
@%n.service
alla sezione
[Unit]
.
%n
passa il nome dell'unità al template.
Nota
Se si configura la sicurezza di sSMTP secondo quanto riportato in
sSMTP#Sicurezza
, l'utente
nobody
non avrà accesso a
/etc/ssmtp/ssmtp.conf
e il comando
systemctl start status_email_user@dbus.service
fallirà. Una soluzione consiste nell'utilizzare
root
come User nell'unità
status_email_user@.service
.
Se si tenta di utilizzare
mail -s somelogs address
nello script email,
mail
eseguirà un fork e systemd terminerà il processo mail non appena rileverà l'uscita dello script. Per rendere mail non-forking, utilizzare il comando
mail -Ssendwait -s somelogs
address
.
Suggerimento
Le versioni più recenti di systemd raccomandano l'uso di
DynamicUser=true
in sostituzione di
User=nobody
, che è ora sconsigliato. Si veda
issue 428 su GitHub
per ulteriori dettagli.
Spegnimento automatico di un hard disk esterno all'arresto
Si veda
Udisks (Italiano)#Spegnimento automatico di un hard disk esterno all'arresto
.
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#Filtrare l'output
per maggiori dettagli.
Suggerimento
È possibile cancellare lo stato "failed" delle unità, rimuovendole dall'output di
systemctl --failed
:
# systemctl reset-failed unit
Si noti che questo solitamente scarica l'unità (vedere la documentazione di
CollectMode
in
systemd.unit(5)
), il che in particolare fa sì che
systemctl status
non ne riporti più lo stato di errore o i log.
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 la
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#Limite di dimensione del journal
.
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
.
Errore "Unit xxx.service not found", ma il servizio esiste
Potreste stare tentando di avviare o abilitare un'unità utente come se fosse un'unità di sistema.
systemd.unit(5)
indica dove risiede ciascun tipo di unità. Per impostazione predefinita,
systemctl
opera sui servizi di sistema.
Vedere
systemd/User
per ulteriori dettagli.
Rinnovare manualmente LoaderDevicePartUUID dopo aver cambiato l'UUID della partizione EFI
Alcuni bootloader impostano la variabile
LoaderDevicePartUUID
solo quando è vuota. Di conseguenza, anche se l'UUID della partizione EFI cambia, il bootloader non aggiornerà
LoaderDevicePartUUID
. Eliminando la variabile EFI con i comandi seguenti, il bootloader la ripopolerà con il nuovo UUID.
# chattr -i /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
# rm /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
Ulteriori risorse
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
.