SystemD è un anzi IL gestore di sistema e di servizi per Linux.
Fornisce un manager di sistema e di servizi che e` avviato con PID 1 (inizio di tutto) e avvia il resto del sistema.
SystemD fornisce una notevole capacità di parallelizzazione (avviare più cose contemporaneamente) e sequenza d’avvio, usa socket e D-Bus per l'avvio dei demoni (gestione sicura e standard), offre un avvio su richiesta dei demoni (un sistema centralizzato e unico), tiene traccia dei processi con l'utilizzo del control groups di Linux (anche dinamicamente, quindi sicurezza), supporta lo snapshotting (fissare un configurazione per usarla più tardi o in sostituzione) e il restore (usare una configurazione precedente) dello stato del sistema, mantiene i punti di mount e di automount (collegamenti disco e altro) e implementa un elaborato servizio di controllo logico basato sulle relazioni delle dipendenze (un servizio non può fare di tutto ma solo quello preordinato).
SystemD supporta SysV e LSB, inoltre sostituisce sysvinit oramai vecchio. Include un demone per il logging, utility per controllare aspetti base del sistema come hostname, data, locale, lista degli utenti loggati; puo` avviare containers e macchine virtuali. Fornisce demoni per gestire la rete, sincronizzazione dell'orario, forwarding di log e name resolution ma anche altro che ci si possa inventare. Fornisce anche librerie d’appoggio e utility per la programmazione vera e propria dei demoni/servizi. Non esiste più la differenza fra Servizi e Demoni, ovvero servizi di basso livello e privilegiati (Demoni) e altri servizi.
In SUSE ma non nativi:
apparmor
cycle
ipconfig
nfs
ntp
xdm
I motivi di questo passaggio da Init al SystemD sono tanti esempio il motivo per cui Arch è passato a SystemD, è in questo post. Oramai solo Slackware è l’unica distro base che non lo usa ma usa InitD.
Systemctl il controllo
Il principale comando usato per controllare SystemD è systemctl. Alcuni degli utilizzi possibili sono l'esame dello stato del sistema e la gestione del sistema e dei servizi.
ATTENZIONE: Se vuoi usare il systemctl per controllare un'istanza di SystemD su una macchina remota ed userà SSH, usa lo switch -H <user>@<host>.
-Analizzare lo stato del sistema
Mostra lo stato del sistema:
$ systemctl status
Lista della unità attive:
$ systemctl
oppure:
$ systemctl list-units
Lista delle unità che hanno avuto problemi:
$ systemctl –failed
I file delle unità disponibili possono essere visti in
/usr/lib/systemd/system/
/etc/systemd/system/
(questi ultimi hanno la precedenza sui primi). Si possono vedere le unità installate con:
$ systemctl list-unit-files
Usare le unità servizi/ecc.
Le unità possono essere, per esempio, servizi (.service e comprende anche i demoni), punti di mount (.mount), dispositivi (.device) oppure sockets (.socket).
Quando si usa systemctl, occorre specificare sempre il nome completo dell'unità compreso il suffisso (esempio “sshd.socket”).
Esistono tuttavia delle scorciatoie quando si specifica l'unità nei seguenti comandi systemctl:
Se non si specifica il suffisso, per systemctl sarà sottinteso .service. Per esempio, netctl e netctl.service sono equivalenti. Il comportamento però è scorretto.
I punti di mount saranno automaticamente tradotti nella appropriata unità .mount. Per esempio, specificare /home è equivalente a home.mount. Il comportamento però è scorretto.
Come i punti di mount, anche i dispositivi sono automaticamente tradotti nell'appropriata unità .device, quindi specificare /dev/sda2 è equivalente a dev-sda2.device. Il comportamento però è scorretto.
Vedi systemd.unit(5) per dettagli.
Nota: Alcune unit contengono una @ (e.g. [email protected]: questo significa che sono istanze di un template, il cui filename non contiene la parte string (e.g. [email protected]). string e` chiamato identificatore dell'istanza ed e` simile all'argomento passato al template quando viene richiamato con il comando systemctl: nelle unit verra` sostituico con %i. Per essere piu` accurati, prima di tentare di istanziare [email protected], SystemD cerchera` una unit con il nome esatto.
-Comandi systemctl
Attivare immediatamente una unità:
# systemctl start unit
Fermare immediatamente una unità:
# systemctl stop unit
Riavviare una unità:
# systemctl restart unit
Ricaricare la configurazione di una unit:
# systemctl reload unit
Mostrare lo stato di una unità, compreso se sta funzionando o no:
$ systemctl status unit
Controllare se una unità è già attivata o no:
$ systemctl is-enabled unit
Attivare l'avvio automatico al boot:
# systemctl enable unit
Attivare l'avvio automatico al boot e avviare immediatamente una unit:
# systemctl enable --now unit
Disattivare l'avvio automatico al boot:
# systemctl disable unit
Unmask di una unit:
# systemctl unmask unit
Mostra la pagina del manuale associata a una unità (non supportato dai files .unit):
$ systemctl help unit
Ricaricare systemd, controllo per nuove o modificate unità:
# systemctl daemon-reload
Power management
polkit è indispensabile per la gestione energetica. Se ci si trova in una sessione locale di systemd-logind e non ci sono altre sessioni attive, il seguente comando funzionerà senza i privilegi di root. Altrimenti (per esempio se un altro utente è loggato in una console), SystemD automaticamente richiederà la password di root.
Riavvio del sistema:
$ systemctl reboot
Spegnimento del sistema:
$ systemctl poweroff
Sospensione del sistema:
$ systemctl suspend
Ibernazione del sistema:
$ systemctl hibernate
Stato ibrido di riposo (o suspend-to-both, non supportato da tutti i computer):
$ systemctl hybrid-sleep
-Avviare DM con systemd
Per avviare il login grafico (DM), abilitare il demone del suo Display Manager corrispondente e attualmente esistono i .service per SDDM, GDM, KDM (abbandonato da KDE per SDDM, QML based X11 e Wayland display manager), SLiM, XDM, LXDM e LightDM. Vanno scritti in minuscolo.
OpenSUSE usa SDDM per KDE e come base, e GDM per Gnome.
# systemctl enable gdm
In caso d’errore: potrebbe essere ancora presente l'impostazione di default.target di una vecchia installazione, procedere come segue:
# ls -l /etc/systemd/system/default.target
/etc/systemd/system/default.target -> /usr/lib/systemd/system/graphical.target
è sufficiente eliminare il link simbolico e SystemD utilizzerà il default.target predefinito (per esempio graphical.target).
# rm /etc/systemd/system/default.target
Usare systemd-logind
Per controllare lo stato della propria sessione utente, si usa loginctl.
Tutte le azioni di PolicyKit come la sospensione del sistema o il montaggio di dispositivi esterni funzioneranno automaticamente.
$ loginctl show-session $XDG_SESSION_ID
Configurazione nativa
Nota: E' possibile che ci sia bisogno di creare questi files. Tutti i file devono avere i permessi a 644 e il proprietario root:root
-Hostname
L'hostname (nome della macchina) è configurato in /etc/hostname. Il file può contenere il nome del dominio di sistema, se esiste, tuttavia nel momento di scrivere hostnamectl non si può configurare il FQDN. Per configurare l'hostname corto:
# hostnamectl set-hostname myhostname
Non scrivete direttamente nel file! In yast2-alternatives esiste il modulo per Yast.
-Impostazioni locali
Le impostazioni locali di default sono configurate in /etc/locale.conf Per configurare il locale di default:
# localectl set-locale LANG="it_IT.utf8"
Non scrivete direttamente nel file! Vedere localectl(1) e locale.conf(5) per dettagli. Per ulteriori informazioni vedere Locale.
Esempio di file:
/etc/locale.conf
LANG=it_IT.utf8
Nota: I parametri ammessi sono: LANG=, LANGUAGE=, LC_CTYPE=, LC_NUMERIC=, LC_TIME=, LC_COLLATE=, LC_MONETARY=, LC_MESSAGES=, LC_PAPER=, LC_NAME=, LC_ADDRESS=, LC_TELEPHONE=, LC_MEASUREMENT=, LC_IDENTIFICATION=. Si consiglia di aggiungere LC_MESSAGES=it_IT.UTF-8 .
Maggiori informazioni in https://jlk.fjfi.cvut.cz/arch/manpages/man/locale.conf.5
--Console virtuale
La console virtuale (ovvero la mappatura della tastiera, i caratteri della console e la mappatura della console) è configurata in /etc/vconsole.conf:
KEYMAP=it
FONT=
FONT_MAP=
Nota: Da systemd-194, si utilizzano i caratteri integrati nel kernel e la mappatura della tastiera "us" se KEYMAP= e FONT= sono vuoti o non configurati. Nel caso è ininfluente.
Un altro modo di configurare la mappatura della tastiera è:
# localectl set-keymap it
localectl può essere usato anche per configurare la tastiera in ambiente X:
# localectl set-x11-keymap it
Esiste un modulo Yast per configurarlo.
--Orario di sistema
SystemD usa UTC di default per l'orologio hardware.
Orologio hardware in localtime
Se si vuole cambiare l'orologio hardware ad usare l'orario locale (ALTAMENTE SCONSIGLIATO):
# timedatectl set-local-rtc true
Se si vuole riconvertirlo a UTC:
# timedatectl set-local-rtc false
Attenzione che, se l'orologio hardware è configurato a localtime, la gestione dell'orario legale è persa. I Kernel recenti configurano l'orario di sistema dall'orologio hardware direttamente al boot, presupponendo che l'orologio hardware sia impostato a UTC. Questo significa che se l'orologio hardware è su locale l'orologio di sistema sarà prima configurato sbagliato e poi corretto ad ogni boot. Questa è la causa di alcuni noiosi bugs dato che il “tempo che torna indietro”.
Una ragione per permettere che l'orologio hardware sia settato sul'orario locale è quella del dual boot con Windows. Tuttavia, Windows è in grado di gestire l'orario con l'orologio hardware settato su UTC con un semplice aggiustamento del registro di sistema.
--Moduli del Kernel
Ad oggi, tutti i moduli necessari da caricare sono gestiti automaticamente da udev, cosicché, se non si vuole usare qualcuno dei moduli fuori dal kernel, non c'è bisogno di mettere i moduli che dovrebbero essere caricati al boot in nessun file di configurazione. Tuttavia, ci sono rari casi in cui si vuole caricare un modulo extra durante il processo di avvio oppure evitare il caricamento di un altro perché il computer funzioni correttamente.
---Moduli extra da caricare all'avvio
I moduli extra al kernel da caricare durante il boot sono configurati in una lista statica in /etc/modules-load.d/. Ogni file di configurazione ha il nome nello stile di /etc/modules-load.d/<programma>.conf/
I files di configurazione dovrebbero semplicemente contenere una lista con i nomi dei moduli da caricare, separati dal tasto INVIO.
Esempio /etc/modules-load.d/virtio-net.conf :
# Carica virtio-net.ko al boot
virtio-net
vedere modules-load.d(5) per maggiori dettagli.
---Configurare le opzioni dei moduli
Ulteriori opzioni per i moduli devono essere impostati in /etc/modprobe.d/modprobe.conf.
Esempio:
Abbiamo il file /etc/modules-load.d/loop.conf con all'interno il modulo loop da far caricare durante la fase di boot.
in /etc/modprobe.d/modprobe.conf specifichiamo le opzioni addizionali, es. options loop max_loop=64
In seguito, l'opzione appena impostato potrebbe essere verificata tramite cat /sys/module/loop/parameters/max_loop
---Blacklisting
Per evitare il caricamento di alcuni moduli del kernel si utilizza la stessa modalità degli initscripts in quanto è attualmente gestito da kmod. Vedere Blacklist dei moduli per maggiori dettagli.
-Montaggio dei filesystem
La configurazione di default controlla e monta i filesystems prima di avviare i servizi ai quali occorre che siano montati!
Per esempio, SystemD automaticamente si assicura che il montaggio di filesystems come NFS o Samba avvenga solo dopo che la rete è attiva. Pertanto, il montaggio dei filesystems, sia locali che remoti, specificati in /etc/fstab dovrebbe funzionare senza problemi.
Vedere systemd.mount(5) per dettagli.
Automount
Se si possiede una grande partizione /home, sarebbe meglio permettere ai servizi che non dipendono da essa di avviarsi durante il controllo di /home da parte di fsck. Ciò può essere ottenuto aggiungendo la seguente opzione alla riga della partizione di /home in /etc/fstab:
noauto,x-systemd.automount
Questo controllerà e monterà /home al primo accesso, e il kernel memorizzerà in un buffer tutti gli accessi ai file in /home finché non sarà pronta.
Nota: questo renderà il filesystem /home di tipo autofs, che è ignorato da mlocate di default. La velocità di montaggio automatico di /home non può essere maggiore di un secondo o due, a seconda del proprio sistema, quindi è possibile che non valga la pena di utilizzare questo trucco.
Lo stesso si può applicare al montaggio dei filesystems remoti. Se si desidera montarli successivamente all'accesso occorrerà usare i parametri noauto,x-systemd.automount. In aggiunta, si può usare l'opzione x-systemd.device-timeout=# per specificare un tempo di timeout in caso la risorsa di rete non sia disponibile.
Se si hanno filesystems criptati con keyfiles, si può comunque aggiungere il parametro noauto alla corrispondente riga in /etc/crypttab. SystemD non aprirà il supporto corrispondente all'avvio, ma aspetterà finché non avverrà un accesso e quindi automaticamente aprirà il keyfile specifico prima di montarlo. Questo potrebbe far risparmiare un po' di secondi al boot se si sta per esempio utilizzando un supporto RAID criptato, in quanto SystemD non deve aspettare finché il dispositivo non sarà disponibile. Per esempio:
/etc/crypttab
data /dev/md0 /root/key noauto
Attenzione: Se si possiede un volume LVM non attivato durante l'initramfs, attivare il servizio lvm-monitoring:
# systemctl enable lvm-monitoring.service
--ACPI power management
SystemD gestisce degli eventi ACPI relativi all'alimentazione. Possono essere configurati attraverso le seguenti opzioni di /etc/systemd/logind.conf:
HandlePowerKey: Specifica che azione deve essere eseguita quando viene premuto il bottone di avvio
HandleSuspendKey: Specifica che azione deve essere eseguita quando viene premuto il bottone di sospensione
HandleHibernateKey: Specifica che azione deve essere eseguita quando viene premuto il bottone di ibernazione
HandleLidSwitch: Specifica che azione deve essere eseguita quando il coperchio del portatile viene chiuso.
Le azioni specificate possono essere una qualsiasi di ignore, poweroff, reboot, halt, suspend, hibernate, hybrid-sleep o kexec.
Se queste opzioni non sono configurate, SystemD userà quelle di default: HandlePowerKey=poweroff, HandleSuspendKey=suspend, HandleHibernateKey=hibernate, HandleLidSwitch=suspend.
Nota: Digitare
systemctl restart systemd-logind.service
perchè le modifiche abbiano effetto.
Nell'attuale versione di systemd, le opzioni Handle* saranno applicate al sistema finché non saranno "inibite" (temporaneamente spente) da un programma, come un gestore di alimentazione in un DE. Se questi inibitori non sono usati, si può finire in una situazione in cui SystemD sospende il sistema , poi al risveglio gli altri gestori di alimentazione lo sospendono di nuovo.
--File temporanei
Gestione dei files temporanei.
Systemd-tmpfiles mantiene la configurazione dei file in /usr/lib/tmpfiles.d/ e in /etc/tmpfiles.d/ per descrivere la creazione, la pulizia e la rimozione dei files e delle cartelle temporanee e volatili che normalmente risiedono in cartelle come /run o /tmp ma anche da altre parti.
Ogni file di configurazione prende il nome nello stile di /etc/tmpfiles.d/<program>.conf
Ciò sovrascriverà ogni file in /usr/lib/tmpfiles.d/ con lo stesso nome.
I tmpfiles sono normalmente forniti assieme al service files per creare cartelle che certi demoni si aspettano di trovare esistenti. Per esempio il demone Samba si aspetta che esista la cartella /run/samba per ottenere i permessi corretti. Il corrispondente tmpfile è qualcosa del genere:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
I tmpfiles possono anche essere usati per scrivere valori in certi files al boot. Per esempio, se si usa /etc/rc.local per disabilitare il risveglio del sistema attraverso dispositivi USB con echo USBE > /proc/acpi/wakeup, si può usare in alternativa il seguente tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
w /proc/acpi/wakeup - - - - USBE
Vedi tmpfiles.d(5) per i dettagli.
Nota: Questo metodo potrebbe non funzionare per impostare le opzioni in /sys poiché il servizio systemd-tmpfiles-setup può eseguirsi prima che i moduli delle periferiche appropriate siano caricati. In questo caso si potrebbe verificare che il modulo abbia un parametro per l'opzione che si desidera impostare con modinfo <module> e impostare questa opzione con un file di configurazione in /etc/modprobe.d[broken link: invalid section]. In caso contrario si dovrà scrivere una regola udev per impostare l' attributo appropriato non appena viene visualizzato il dispositivo.
--Unità
Un file di configurazione di unità racchiude informazioni riguardanti un servizio, un socket, un dispositivo, un punto di montaggio, un punto di automontaggio, un file o una partizione di swap, un obbiettivo di avvio, un percorso del filesystem oppure un controllo schedulato da SystemD e altro. La sintassi è ispirata da "XDG Desktop Entry Specification" files di tipo .desktop, che a loro volta richiamano i files .ini di window.
Vedi systemd.unit(5) per maggiori informazioni.
--Gestire le dipendenze
Con SystemD le dipendenze possono essere risolte progettando le unità correttamente. Il caso più tipico è che l'unità A richieda l'unità B per poter funzionare prima che A parta. In questo caso aggiungere Requires=B e After=B alla sezione [Unit] di A. Se la dipendenza è opzionale aggiungere, invece, Wants=B e After=B. Notare che Wants= e Requires= non includono After=, il che significa che se After= non è specificato, le due unità saranno avviate in parallelo.
Le dipendenze sono di solito posizionate sui .service e non sui .target. Per esempio, network.target è richiamato qualsiasi sia il servizio che configuri l'interfaccia di rete, quindi avviare successivamente la propria unità personalizzata è sufficiente in quanto network.target è avviato comunque.
--Type
Ci sono parecchi tipi differenti di avvio da considerare quando si scrive un servizio personalizzato. Ciò è configurato tramite il parametro Type= nella sezione [Service].
Type=simple(default): SystemD presuppone che il servizio deve essere avviato immediatamente. Il processo non può essere suddiviso. Non usare questo tipo se altri servizi hanno bisogno di essere disposti con questo servizio, a meno che non sia attivato dal socket.
Type=forking: SystemD presuppone che il servizio deve essere avviato prima il processo sia suddiviso e il genitore sia concluso. Per i classici demoni usare questo tipo a meno che non si sappia che non è necessario, come la maggior parte dei demoni usa il double-forking per segnalare che sono pronti. Occorre pure specificare PIDFile= perché SystemD tenga traccia del processo principale.
Type=oneshot: E' utile per scripts che eseguono un singolo lavoro e si concludono. Si può configurare pure con RemainAfterExit=yes in modo che SystemD consideri il servizio ancora attivo anche dopo che il processo si è concluso.
Type=notify: Identico a Type=simple, ma con l'accorgimento che il demone invierà un segnale a SystemD quando sarà pronto. L'implementazione di riferimento per questa notifica è fornita da libsystemd-daemon.so.
Type=dbus: Il servizio è considerato pronto quando lo specificato BusName appare nel sistema di bus si DBus.
--Rimpiazzare le unità fornite
Per editare il file unit fornito da un pacchetto, si può creare una cartella chiamata /etc/systemd/system/<unit>.d/
per esempio
/etc/systemd/system/httpd.service.d/
e mettere i files *.conf in essa per sovrascrivere e aggiungere nuove opzioni. SystemD controllerà questi files *.conf e li applicherà al di sopra degli originali. Per esempio, se si vuole semplicemente aggiungere un dipendenza all'unità si può creare il seguente file:
/etc/systemd/system/<unit>.d/customdependency.conf
[Unit]
Requires=<new dependency>
After=<new dependency>
Poi eseguire i comandi seguenti perché le modifiche abbiano effetto:
# systemctl daemon-reload
# systemctl restart <unit>
Da notare che quando l'unità originale in /usr/lib/ cambia a causa di un aggiornamento, le modifiche non si rifletteranno automaticamente sulla propria unità personalizzata in /etc/. In aggiunta occorre riattivarla manualmente con systemctl reenable <unit>. E' raccomandato usare il metodo con il *.conf descritto sopra.
Suggerimento: Si può usare systemd-delta per vedere quali unità sono state sovrascritti e quali esattamente sono state modificate.
Siccome le unità saranno aggiornate di volta in volta , usare systemd-delta per la manutenzione del sistema.
--Targets
Quello dei "runlevels" è un concetto superato in SystemD anche se all’inizio lo supportava.
SystemD ha il concetto di target (lett. "bersagli", si può pensare al concetto del gruppo) che adempiono uno scopo simile a quello dei runlevel, ma che hanno un comportamento leggermente differente e più potente.
Ogni target ha un nome anziché un numero ed è usato per raggiungere uno specifico scopo con la possibilità di averne più di uno attivo nello stesso momento.
Alcuni targets sono attivati ereditando tutti dei servizi di un altro target e implementandolo di servizi addizionali (i targets sono gruppi di target). Ci sono target che simulano i runlevel di SystemVinit, è così possibile passare da un target all'altro utilizzando il comando telinit RUNLEVEL.
---Conoscere il target attuale
Il seguente comando dove essere usato sotto SystemD al posto del deprecato runlevel:
$ systemctl list-units --type=target
---Creare un target personalizzato
I runlevels sono assegnati ad uno specifico scopo quindi per implentarli, si suggerisce di dare un nuovo nome al target di SystemD come /etc/systemd/system/<your target> che prenda come base une dei runlevels esistenti (vedi /usr/lib/systemd/system/graphical.target
come esempio), creare una cartella
/etc/systemd/system/<your target>.wants
, e fare un collegamento ai servizi addizionali da
/usr/lib/systemd/system/
che si intendono attivare.
---Targets table
SysV Runlevel | SystemD Target | Notes |
0 | runlevel0.target, poweroff.target | Ferma il sistema. |
1, s, single | runlevel1.target, rescue.target | Modalità utente singolo (single user). |
2, 4 | runlevel2.target, runlevel4.target, multi-user.target | Definita dall'utente. Preconfigurata a 3. Livello protetto. |
3 | runlevel3.target, multi-user.target | Multi-user, non-grafico. Utente che fa login via multiple-consoles o via network. Livello protetto. |
5 | runlevel5.target, graphical.target | Multi-user, grafica. Desktop. Solitamente ha tutti i servizi del runlevel 3 con l'aggiunta di un login grafico. |
6 | runlevel6.target, reboot.target | Riavvio |
emergency | emergency.target | Console di emergenza |
---Cambiare il target corrente
In SystemD i targets sono esplicitati per mezzo di "target units". Si possono cambiare così:
# systemctl isolate graphical.target
Questo comando cambierà solamente il target corrente e non avrà nessun effetto sul prossimo avvio. Nota: Questo è equivalente ai comandi telinit 3 oppure telinit 5 in Sysvinit.
---Cambiare il target predefinito all'avvio
Il target standard è default.target, che è abbinato in modo predefinito a graphical.target (che corrisponde al vecchio runlevel 5, livello grafico).
Per cambiare il target predefinito al boot, aggiungere uno dei seguenti parametri del kernel alla linea nel bootloader:
Attenzione: L'estensione .target può essere stata tralasciata.
systemd.unit=multi-user.target (che corrisponde al vecchio runevel 3),
systemd.unit=rescue.target (che corrisponde al vecchio runevel 1).
In alternativa si può lasciare il bootloader inalterato e cambiare default.target. Ciò può essere fatto usando systemctl:
# systemctl enable multi-user.target
L'effetto di questo comando si nota nell'output di systemctl in quanto viene creato un link simbolico al nuovo target predefinito /etc/systemd/system/default.target. Questo funziona solo se in:
[Install]
Alias=default.target
si trova nel file di configurazione del target. Attualmente, sia multi-user.target che graphical.target lo possiedono.
-Timers
Lo tratto qui.
http://trucchisuse.altervista.org/blog/systemd-sostituisce-cron/
-Il Journal
Fin dalla versione 38 SystemD possiede un proprio sistema di log (messaggi di sistema) chiamato journal.
Nota: Far funzionare il demone syslog non è più richiesto.
Per leggere il log si usa:
# journalctl
Di default quando è configurato in
/etc/systemd/journald.conf
a
Storage= auto
il journal scrive in
/var/log/journal/
La directory /var/log/journal/ è parte di core/systemd.
Se si è cancellata intenzionalmente o se qualche programma lo ha fatto SystemD non lo ricreerà automaticamente, tuttavia sarà ricreata durante il prossimo aggiornamento indici/riavvio di SystemD e fino a quel momento i log che erano scritti in /run/systemd/journal saranno persi fino al riavvio.
--Filtrare l' output
journalctl permette di filtrare l'output secondo specifici campi.
Esempi:
Mostrare tutti i messaggi di questo boot:
# journalctl -b
Tuttavia, spesso un utente può essere interessato ai messaggi non del corrente boot, e come workaround al momento si può usare:
# journalctl --since=today | tac | sed -n '/-- Reboot --/{n;:r;/-- e Reboot --/q;p;n;b r}' | tac
,che provoca che il precedente boot sia come scaturito oggi.
Tenere presente che, se ci sono molti messaggi per il giorno corrente, l'output di questo comando può essere “ritardato” (lento) per un bel po 'di tempo.
--Comandi di uso comune
Seguire i nuovi messaggi:
# journalctl -f
Mostrare tutti i messaggi di un eseguibile specifico:
# journalctl /usr/lib/systemd/systemd
Mostrare tutti i messaggi di uno specifico processo:
# journalctl _PID=1
Mostrare tutti i messaggi di una specifica unità:
# journalctl -u netcfg
Vedere journalctl(1) e systemd.journal-fields per dettagli.
--Limiti alla dimensione del journal
Se il journal è persistente (non volatile) la sua dimensione è fissata al 10% della dimensione del rispettivo file system.
Per esempio con /var/log/journal allocato su una partizione di root di 50 GiB comporterebbe 5 GiB di dati nel journal.
La dimensione massima del journal persistente può essere controllata attraverso il paraetro SystemMaxUse in
/etc/systemd/journald.conf
, così per limitarla ad esempio a 50 MiB decommentare ed editare la linea corrispondente linea:
SystemMaxUse=50M
Esistono anche altri parametri come “Compress=yes” per limitare le dimensione.
Fare riferimento a journald.conf(5) per maggiori dettagli.
--Journald coesistente con syslog
La compatibilità con il classico syslog è fornita dal socket /run/systemd/journal/syslog, attraverso il quale passano tutti i messaggi.
Per rendere il demone syslog funzionante con il journal, si deve associarlo a questo socket anziché a /dev/log .
# systemctl enable syslog-ng
Una buona guida a journalctl è qui.
-Correzione di errori
---Lo spegnimento e il riavvio sono terribilmente lunghi
Se il processo di spegnimento impiega molto tempo (oppure sembra bloccarsi) probabilmente la colpa è da attribuirsi alla mancata chiusura di un servizio.
SystemD attende del tempo per la chiusura di ogni servizio prima di chiuderlo forzatamente. Per vedere se si soffre di questo problema vedere questo articolo.
---I processi di breve durata non registrano nessun output
Se journalctl -u foounit.service non mostra nessun output per un processo di breve durata, controllare il PID. In questo modo vedrete più il dettaglio e quindi la sua registrazione.
Per esempio, se systemd-modules-load.service fallisce, e systemctl status systemd-modules-load evidenzia che è eseguito con PID 123, è possibile vedere l'output del journal per quel PID, per esempio journalctl -b _PID=123.
I campi con metadata del journal come _SYSTEMD_UNIT e _COMM sono raccolti in modo asincrono e fanno affidamento sulla cartella /proc per il processo esistente. La sistemazione di questo richiede una sistemazione del Kernel per fornire questi dati per mezzo di una connessione socket, come per SCM_CREDENTIALS.
---Diagnosi dei problemi al Boot
Avviare il sistema con questi parametri sulla linea di comando del kernel:
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
Rimuovere quiet dalla line di comando del Kernel
È inoltre possibile aggiungere systemd.sysv_console = 1 (0: disabilitato, 1: abilitato) per visualizzare l'output initscripts di SysV legacy sulla console.
modificare /etc/systemd/system.conf per incrementare la verbosità:
LogLevel=debug
LogTarget=syslog-or-kmsg
SysVConsole=yes