Nei primi due articoli di questa serie, ho esplorato la sequenza di avvio del sistema Linux. Nel primo articolo, ho esaminato le funzioni e l'architettura di systemd e la controversia sul suo ruolo come sostituto del vecchio programma init di SystemV e degli script di avvio. E nel secondo articolo, ho esaminato due importanti strumenti di sistema, systemctl e journalctl, e ho spiegato come passare da una destinazione all'altra e cambiare la destinazione predefinita.
In questo terzo articolo, esaminerò le unità systemd in modo più dettagliato e come utilizzare il comando systemctl per esplorare e gestire le unità. Spiegherò anche come fermare e disabilitare le unità e come creare una nuova unità di montaggio systemd per montare un nuovo filesystem e consentirne l'avvio durante l'avvio.
Preparazione
Altro sugli amministratori di sistema
- Abilita blog Sysadmin
- The Automated Enterprise:una guida alla gestione dell'IT con l'automazione
- eBook:Ansible Automation per SysAdmins
- Racconti dal campo:una guida per l'amministratore di sistema all'automazione IT
- eBook:una guida a Kubernetes per SRE e amministratori di sistema
- Ultimi articoli sull'amministratore di sistema
Tutti gli esperimenti in questo articolo devono essere eseguiti come utente root (se non diversamente specificato). Alcuni dei comandi che elencano semplicemente varie unità di sistema possono essere eseguiti da utenti non root, ma i comandi che apportano modifiche non possono. Assicurati di eseguire tutti questi esperimenti solo su host o macchine virtuali (VM) non di produzione.
Uno di questi esperimenti richiede il pacchetto sysstat, quindi installalo prima di andare avanti. Per Fedora e altre distribuzioni basate su Red Hat puoi installare sysstat con:
dnf -y install sysstatsysstat RPM installa diversi strumenti statistici che possono essere utilizzati per la determinazione dei problemi. Uno è System Activity Report (SAR), che registra molti punti dati sulle prestazioni del sistema a intervalli regolari (ogni 10 minuti per impostazione predefinita). Invece di essere eseguito come demone in background, il pacchetto sysstat installa due timer di sistema. Un timer viene eseguito ogni 10 minuti per raccogliere i dati e l'altro viene eseguito una volta al giorno per aggregare i dati giornalieri. In questo articolo, esaminerò brevemente questi timer ma attendo di spiegare come creare un timer in un articolo futuro.
suite di sistema
Il fatto è che systemd è più di un semplice programma. È una vasta suite di programmi tutti progettati per funzionare insieme per gestire quasi ogni aspetto di un sistema Linux in esecuzione. Un'esposizione completa di systemd richiederebbe un libro da solo. La maggior parte di noi non ha bisogno di comprendere tutti i dettagli su come si integrano tutti i componenti di systemd, quindi mi concentrerò sui programmi e sui componenti che consentono di gestire vari servizi Linux e gestire file di registro e diari.
Struttura pratica
La struttura di systemd, al di fuori dei suoi file eseguibili, è contenuta nei suoi numerosi file di configurazione. Sebbene questi file abbiano nomi ed estensioni di identificatori diversi, sono tutti chiamati file "unità". Le unità sono la base di tutto il sistemad.
I file unit sono file di testo normale ASCII accessibili e che possono essere creati o modificati da un amministratore di sistema. Esistono diversi tipi di file di unità e ognuno ha la propria pagina man. La Figura 1 elenca alcuni di questi tipi di file unit in base alle estensioni dei nomi di file ea una breve descrizione di ciascuno.
| unità di sistema | Descrizione |
|---|---|
| .automount | Il .automount le unità vengono utilizzate per implementare on-demand (ad esempio, plug and play) e il montaggio di unità di filesystem in parallelo durante l'avvio. |
| .device | Il .device i file unit definiscono l'hardware e i dispositivi virtuali che sono esposti all'amministratore di sistema nella /dev/directory . Non tutti i dispositivi hanno file di unità; in genere, i dispositivi a blocchi come dischi rigidi, dispositivi di rete e alcuni altri hanno file di unità. |
| .mount | Il .mount unit definisce un punto di montaggio sulla struttura della directory del filesystem Linux. |
| .scope | Il .scope l'unità definisce e gestisce un insieme di processi di sistema. Questa unità non è configurata utilizzando file di unità, ma viene creata a livello di codice. Secondo il systemd.scope man page, "Lo scopo principale delle unità di ambito è raggruppare i processi di lavoro di un servizio di sistema per l'organizzazione e per la gestione delle risorse." |
| .service | Il servizio i file unit definiscono i processi gestiti da systemd. Questi includono servizi come crond cups (Common Unix Printing System), iptables, servizi di gestione del volume logico multiplo (LVM), NetworkManager e altro ancora. |
| .slice | Il .slice unità definisce una "fetta", che è una divisione concettuale delle risorse di sistema correlate a un gruppo di processi. Puoi pensare a tutte le risorse di sistema come a una torta e a questo sottoinsieme di risorse come a una "fetta" di quella torta. |
| .socket | Il .socket le unità definiscono socket di comunicazione tra processi, come socket di rete. |
| .swap | Il .swap le unità definiscono dispositivi o file di scambio. |
| .target | Il .target le unità definiscono gruppi di file di unità che definiscono punti di sincronizzazione di avvio, runlevel e servizi. Le unità target definiscono i servizi e le altre unità che devono essere attive per iniziare correttamente. |
| .timer | Il .timer unit definisce i timer che possono avviare l'esecuzione del programma a orari specificati. |
systemctl
Ho esaminato le funzioni di avvio di systemd nel secondo articolo e qui esplorerò ulteriormente le sue funzioni di gestione dei servizi. systemd fornisce il systemctl comando utilizzato per avviare e arrestare i servizi, configurarli per l'avvio (o meno) all'avvio del sistema e monitorare lo stato corrente dei servizi in esecuzione.
In una sessione di terminale come utente root, assicurati che la home directory di tale root ( ~ ) è la PWD. Per iniziare a guardare le unità in vari modi, elenca tutte le unità di sistema caricate e attive. systemctl convoglia automaticamente il suo flusso di dati stdout attraverso il meno cercapersone, quindi non devi:
[root@testvm1 ~]# systemctl
UNIT LOAD ACTIVE SUB DESCRIPTION
proc-sys-fs-binfmt_misc.automount loaded active running Arbitrary Executable File>
sys-devices-pci0000:00-0000:00:01.1-ata7-host6-target6:0:0-6:0:0:0-block-sr0.device loaded a>
sys-devices-pci0000:00-0000:00:03.0-net-enp0s3.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:05.0-sound-card0.device loaded active plugged 82801AA AC'97>
sys-devices-pci0000:00-0000:00:08.0-net-enp0s8.device loaded active plugged 82540EM Gigabi>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda1.device loa>
sys-devices-pci0000:00-0000:00:0d.0-ata1-host0-target0:0:0-0:0:0:0-block-sda-sda2.device loa>
<snip – removed lots of lines of data from here>
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
206 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
Mentre scorri i dati nella sessione del terminale, cerca alcune cose specifiche. La prima sezione elenca i dispositivi come dischi rigidi, schede audio, schede di interfaccia di rete e dispositivi TTY. Un'altra sezione mostra i punti di montaggio del filesystem. Altre sezioni includono vari servizi e un elenco di tutti i target caricati e attivi.
I timer sysstat nella parte inferiore dell'output vengono utilizzati per raccogliere e generare riepiloghi delle attività di sistema giornaliere per SAR. SAR è uno strumento molto utile per la risoluzione dei problemi. (Puoi saperne di più nel Capitolo 13 del mio libro Using and Administering Linux:Volume 1, Zero to SysAdmin:Getting Started .)
In fondo, tre righe descrivono i significati degli stati (caricato, attivo e secondario). Premi q per uscire dal cercapersone.
Utilizzare il comando seguente (come suggerito nell'ultima riga dell'output sopra) per vedere tutte le unità installate, caricate o meno. Non riprodurrò l'output qui, perché puoi scorrerlo da solo. Il programma systemctl ha un'eccellente funzione di completamento delle schede che semplifica l'immissione di comandi complessi senza dover memorizzare tutte le opzioni:
[root@testvm1 ~]# systemctl list-unit-filesPuoi vedere che alcune unità sono disabilitate. La tabella 1 nella pagina man per gli elenchi di systemctl e fornisce brevi descrizioni delle voci che potresti vedere in questo elenco. Usa il -t (tipo) opzione per visualizzare solo le unità del timer:
[root@testvm1 ~]# systemctl list-unit-files -t timer
UNIT FILE STATE
[email protected] disabled
dnf-makecache.timer enabled
fstrim.timer disabled
logrotate.timer disabled
logwatch.timer disabled
[email protected] static
mlocate-updatedb.timer enabled
sysstat-collect.timer enabled
sysstat-summary.timer enabled
systemd-tmpfiles-clean.timer static
unbound-anchor.timer enabled
Potresti fare la stessa cosa con questa alternativa, che fornisce molti più dettagli:
[root@testvm1 ~]# systemctl list-timers
Thu 2020-04-16 09:06:20 EDT 3min 59s left n/a n/a systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2020-04-16 10:02:01 EDT 59min left Thu 2020-04-16 09:01:32 EDT 49s ago dnf-makecache.timer dnf-makecache.service
Thu 2020-04-16 13:00:00 EDT 3h 57min left n/a n/a sysstat-collect.timer sysstat-collect.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left mlocate-updatedb.timer mlocate-updatedb.service
Fri 2020-04-17 00:00:00 EDT 14h left Thu 2020-04-16 12:51:37 EDT 3h 49min left unbound-anchor.timer unbound-anchor.service
Fri 2020-04-17 00:07:00 EDT 15h left n/a n/a sysstat-summary.timer sysstat-summary.service
6 timers listed.
Pass --all to see loaded but inactive timers, too.
[root@testvm1 ~]#
Sebbene non ci sia alcuna opzione per eseguire systemctl list-mounts, puoi elencare i file dell'unità del punto di montaggio:
[root@testvm1 ~]# systemctl list-unit-files -t mount
UNIT FILE STATE
-.mount generated
boot.mount generated
dev-hugepages.mount static
dev-mqueue.mount static
home.mount generated
proc-fs-nfsd.mount static
proc-sys-fs-binfmt_misc.mount disabled
run-vmblock\x2dfuse.mount disabled
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount generated
usr.mount generated
var-lib-nfs-rpc_pipefs.mount static
var.mount generated
15 unit files listed.
[root@testvm1 ~]#
La colonna STATE in questo flusso di dati è interessante e richiede un po' di spiegazione. Gli stati "generato" indicano che l'unità di montaggio è stata generata al volo durante l'avvio utilizzando le informazioni in /etc/fstab . Il programma che genera queste unità di montaggio è /lib/systemd/system-generators/systemd-fstab-generator, insieme ad altri strumenti che generano una serie di altri tipi di unità. Le unità di montaggio "statiche" sono per filesystem come /proc e /sys e i relativi file si trovano in /usr/lib/systemd/system directory.
Ora, guarda le unità di servizio. Questo comando mostrerà tutti i servizi installati sull'host, indipendentemente dal fatto che siano attivi o meno:
[root@testvm1 ~]# systemctl --all -t serviceLa parte inferiore di questo elenco di unità di servizio mostra 166 come numero totale di unità caricate sul mio host. Il tuo numero probabilmente sarà diverso.
I file Unit non hanno un'estensione del nome file (come .unit ) per identificarli, in modo da poter generalizzare che la maggior parte dei file di configurazione che appartengono a systemd sono file di unità di un tipo o dell'altro. I pochi file rimanenti sono principalmente .conf file che si trovano in /etc/systemd .
I file delle unità sono archiviati in /usr/lib/systemd directory e le sue sottodirectory, mentre /etc/systemd/ directory e le sue sottodirectory contengono collegamenti simbolici ai file unit necessari alla configurazione locale di questo host.
Per esplorarlo, crea /etc/systemd il PWD ed elencarne il contenuto. Quindi crea /etc/systemd/system la PWD ed elencarne il contenuto ed elencare i contenuti di almeno un paio di sottodirectory della PWD corrente.
Dai un'occhiata a default.target file, che determina a quale destinazione del runlevel verrà avviato il sistema. Nel secondo articolo di questa serie, ho spiegato come modificare la destinazione predefinita dalla GUI (graphical.target ) solo alla riga di comando (multi-user.target ) bersaglio. Il target predefinito sulla mia macchina virtuale di prova è semplicemente un collegamento simbolico a /usr/lib/systemd/system/graphical.target .
Prenditi qualche minuto per esaminare i contenuti di /etc/systemd/system/default.target file:
[root@testvm1 system]# cat default.target
# SPDX-License-Identifier: LGPL-2.1+
#
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes
Tieni presente che ciò richiede multi-user.target; il obiettivo.grafico non può iniziare se multi-user.target non è già attivo e funzionante. Dice anche che "vuole" il display-manager.service unità. Non è necessario soddisfare un "desiderio" affinché l'unità si avvii correttamente. Se il "desiderio" non può essere soddisfatto, verrà ignorato da systemd e il resto del target verrà avviato indipendentemente.
Le sottodirectory in /etc/systemd/system sono elenchi di desideri per vari obiettivi. Dedica qualche minuto per esplorare i file e il loro contenuto in /etc/systemd/system/graphical.target.wants directory.
La unità di sistema la pagina man contiene molte buone informazioni sui file unit, la loro struttura, le sezioni in cui possono essere suddivisi e le opzioni che possono essere utilizzate. Elenca anche molti tipi di unità, ognuno dei quali ha le proprie pagine man. Se vuoi interpretare un file di unità, questo sarebbe un buon punto di partenza.
Unità di servizio
Un'installazione Fedora di solito installa e abilita servizi di cui alcuni host non hanno bisogno per il normale funzionamento. Al contrario, a volte non include i servizi che devono essere installati, abilitati e avviati. I servizi che non sono necessari affinché l'host Linux funzioni come desiderato, ma che sono installati e possibilmente in esecuzione, rappresentano un rischio per la sicurezza e dovrebbero, come minimo, essere interrotti e disabilitati e, nella migliore delle ipotesi, dovrebbero essere disinstallati.
Il comando systemctl viene utilizzato per gestire le unità systemd, inclusi servizi, destinazioni, montaggi e altro. Dai un'occhiata più da vicino all'elenco dei servizi per identificare i servizi che non verranno mai utilizzati:
[root@testvm1 ~]# systemctl --all -t service
UNIT LOAD ACTIVE SUB DESCRIPTION
<snip>
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
cups.service loaded active running CUPS Scheduler
dbus-daemon.service loaded active running D-Bus System Message Bus
<snip>
● ip6tables.service not-found inactive dead ip6tables.service
● ipset.service not-found inactive dead ipset.service
● iptables.service not-found inactive dead iptables.service
<snip>
firewalld.service loaded active running firewalld - dynamic firewall daemon
<snip>
● ntpd.service not-found inactive dead ntpd.service
● ntpdate.service not-found inactive dead ntpdate.service
pcscd.service loaded active running PC/SC Smart Card Daemon
Ho eliminato la maggior parte dell'output del comando per risparmiare spazio. I servizi che mostrano "in esecuzione attiva caricata" sono ovvi. I servizi "non trovati" sono quelli di cui systemd è a conoscenza ma non sono installati sull'host Linux. Se vuoi eseguire quei servizi, devi installare i pacchetti che li contengono.
Nota il pcscd.service unità. Questo è il demone della smart card PC/SC. La sua funzione è quella di comunicare con i lettori di smart card. Molti host Linux, incluse le macchine virtuali, non hanno bisogno di questo lettore né del servizio che viene caricato e occupa memoria e risorse della CPU. Puoi interrompere questo servizio e disabilitarlo, in modo che non si riavvii al prossimo avvio. Per prima cosa, controlla il suo stato:
[root@testvm1 ~]# systemctl status pcscd.service
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: active (running) since Fri 2019-05-10 11:28:42 EDT; 3 days ago
Docs: man:pcscd(8)
Main PID: 24706 (pcscd)
Tasks: 6 (limit: 4694)
Memory: 1.6M
CGroup: /system.slice/pcscd.service
└─24706 /usr/sbin/pcscd --foreground --auto-exit
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
Questi dati illustrano le informazioni aggiuntive fornite da systemd rispetto a SystemV, che segnala solo se il servizio è in esecuzione o meno. Tieni presente che specificando il .service il tipo di unità è opzionale. Ora interrompi e disabilita il servizio, quindi ricontrolla il suo stato:
[root@testvm1 ~]# systemctl stop pcscd ; systemctl disable pcscd
Warning: Stopping pcscd.service, but it can still be activated by:
pcscd.socket
Removed /etc/systemd/system/sockets.target.wants/pcscd.socket.
[root@testvm1 ~]# systemctl status pcscd
● pcscd.service - PC/SC Smart Card Daemon
Loaded: loaded (/usr/lib/systemd/system/pcscd.service; indirect; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2019-05-13 15:23:15 EDT; 48s ago
Docs: man:pcscd(8)
Main PID: 24706 (code=exited, status=1/FAILURE)
May 10 11:28:42 testvm1 systemd[1]: Started PC/SC Smart Card Daemon.
May 13 15:23:15 testvm1 systemd[1]: Stopping PC/SC Smart Card Daemon...
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Main process exited, code=exited, status=1/FAIL>
May 13 15:23:15 testvm1 systemd[1]: pcscd.service: Failed with result 'exit-code'.
May 13 15:23:15 testvm1 systemd[1]: Stopped PC/SC Smart Card Daemon.
La visualizzazione breve della voce di registro per la maggior parte dei servizi evita di dover cercare tra vari file di registro per individuare questo tipo di informazioni. Controlla lo stato delle destinazioni del livello di esecuzione del sistema:è necessario specificare il tipo di unità "destinazione":
[root@testvm1 ~]# systemctl status multi-user.target
● multi-user.target - Multi-User System
Loaded: loaded (/usr/lib/systemd/system/multi-user.target; static; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Multi-User System.
[root@testvm1 ~]# systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
[root@testvm1 ~]# systemctl status default.target
● graphical.target - Graphical Interface
Loaded: loaded (/usr/lib/systemd/system/graphical.target; indirect; vendor preset: disabled)
Active: active since Thu 2019-05-09 13:27:22 EDT; 4 days ago
Docs: man:systemd.special(7)
May 09 13:27:22 testvm1 systemd[1]: Reached target Graphical Interface.
La destinazione predefinita è la destinazione grafica. Lo stato di qualsiasi unità può essere verificato in questo modo.
Si monta alla vecchia maniera
Un'unità di montaggio definisce tutti i parametri richiesti per montare un filesystem su un punto di montaggio designato. systemd può gestire le unità di montaggio con maggiore flessibilità rispetto a quelle che utilizzano /etc/fstab file di configurazione del filesystem. Nonostante ciò, systemd utilizza ancora /etc/fstab file per la configurazione del filesystem e per il montaggio. systemd utilizza il systemd-fstab-generator strumento per creare unità di montaggio transitorie dai dati in fstab file.
Creerò un nuovo filesystem e un'unità di montaggio systemd per montarlo. Se hai spazio su disco disponibile sul tuo sistema di test, puoi farlo insieme a me.
Nota che il gruppo di volumi ei nomi dei volumi logici potrebbero essere diversi sul tuo sistema di test. Assicurati di utilizzare i nomi pertinenti al tuo sistema.
Sarà necessario creare una partizione o un volume logico, quindi creare un filesystem EXT4 su di esso. Aggiungi un'etichetta al filesystem, TestFS e crea una directory per un punto di montaggio /TestFS .
Per provarlo da solo, prima verifica di avere spazio libero sul gruppo di volumi. Ecco come appare sulla mia macchina virtuale in cui ho un po' di spazio disponibile sul gruppo di volumi per creare un nuovo volume logico:
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
└─VG01-tmp 253:5 0 10G 0 lvm /tmp
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]# vgs
VG #PV #LV #SN Attr VSize VFree
VG01 1 6 0 wz--n- <116.00g <23.00g
Quindi crea un nuovo volume su VG01 denominato TestFS . Non è necessario che sia grande; 1GB va bene. Quindi crea un filesystem, aggiungi l'etichetta del filesystem e crea il punto di montaggio:
[root@testvm1 ~]# lvcreate -L 1G -n TestFS VG01
Logical volume "TestFS" created.
[root@testvm1 ~]# mkfs -t ext4 /dev/mapper/VG01-TestFS
mke2fs 1.45.3 (14-Jul-2019)
Creating filesystem with 262144 4k blocks and 65536 inodes
Filesystem UUID: 8718fba9-419f-4915-ab2d-8edf811b5d23
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
[root@testvm1 ~]# e2label /dev/mapper/VG01-TestFS TestFS
[root@testvm1 ~]# mkdir /TestFS
Ora monta il nuovo filesystem:
[root@testvm1 ~]# mount /TestFS/
mount: /TestFS/: can't find in /etc/fstab.
Questo non funzionerà perché non hai una voce in /etc/fstab . Puoi montare il nuovo filesystem anche senza la voce in /etc/fstab utilizzando sia il nome del dispositivo (come appare in /dev ) e il punto di montaggio. Il montaggio in questo modo è più semplice di prima:prima richiedeva il tipo di filesystem come argomento. Il comando mount è ora abbastanza intelligente da rilevare il tipo di filesystem e montarlo di conseguenza.
Riprova:
[root@testvm1 ~]# mount /dev/mapper/VG01-TestFS /TestFS/
[root@testvm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 120G 0 disk
├─sda1 8:1 0 4G 0 part /boot
└─sda2 8:2 0 116G 0 part
├─VG01-root 253:0 0 5G 0 lvm /
├─VG01-swap 253:1 0 8G 0 lvm [SWAP]
├─VG01-usr 253:2 0 30G 0 lvm /usr
├─VG01-home 253:3 0 20G 0 lvm /home
├─VG01-var 253:4 0 20G 0 lvm /var
├─VG01-tmp 253:5 0 10G 0 lvm /tmp
└─VG01-TestFS 253:6 0 1G 0 lvm /TestFS
sr0 11:0 1 1024M 0 rom
[root@testvm1 ~]#
Ora il nuovo filesystem è montato nella posizione corretta. Elenca i file dell'unità di montaggio:
[root@testvm1 ~]# systemctl list-unit-files -t mountQuesto comando non mostra un file per /TestFS filesystem perché non esiste alcun file per esso. Il comando systemctl status TestFS.mount non mostra nemmeno alcuna informazione sul nuovo filesystem. Puoi provarlo utilizzando i caratteri jolly con lo stato systemctl comando:
[root@testvm1 ~]# systemctl status *mount
● usr.mount - /usr
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted)
Where: /usr
What: /dev/mapper/VG01-usr
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:02:26 EDT; 1min 18s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
● run-user-0.mount - /run/user/0
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Thu 2020-04-16 08:52:29 EDT; 1 day 5h ago
Where: /run/user/0
What: tmpfs
● var.mount - /var
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Thu 2020-04-16 12:51:34 EDT; 1 day 1h ago
Where: /var
What: /dev/mapper/VG01-var
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 212.0K
CPU: 5ms
CGroup: /system.slice/var.mount
Questo comando fornisce alcune informazioni molto interessanti sui mount del tuo sistema e viene visualizzato il tuo nuovo filesystem. Il /var e /usr i filesystem sono identificati come generati da /etc/fstab , mentre il tuo nuovo filesystem mostra semplicemente che è stato caricato e fornisce la posizione del file di informazioni in /proc/self/mountinfo file.
Quindi, automatizza questo montaggio. Per prima cosa, fallo alla vecchia maniera aggiungendo una voce in /etc/fstab . Successivamente, ti mostrerò come farlo nel nuovo modo, che ti insegnerà a creare unità e integrarle nella sequenza di avvio.
Smonta /TestFS e aggiungi la seguente riga a /etc/fstab file:
/dev/mapper/VG01-TestFS /TestFS ext4 defaults 1 2Ora monta il filesystem con il più semplice mount comando ed elenca nuovamente le unità di montaggio:
[root@testvm1 ~]# mount /TestFS
[root@testvm1 ~]# systemctl status *mount
<SNIP>
● TestFS.mount - /TestFS
Loaded: loaded (/proc/self/mountinfo)
Active: active (mounted) since Fri 2020-04-17 16:26:44 EDT; 1min 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
<SNIP>
Ciò non ha modificato le informazioni per questo montaggio perché il filesystem è stato montato manualmente. Riavvia ed esegui di nuovo il comando e questa volta specifica TestFS.mount invece di usare il carattere jolly. I risultati per questo montaggio ora sono coerenti con il montaggio all'avvio:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - /TestFS
Loaded: loaded (/etc/fstab; generated)
Active: active (mounted) since Fri 2020-04-17 16:30:21 EDT; 1min 38s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Tasks: 0 (limit: 19166)
Memory: 72.0K
CPU: 6ms
CGroup: /system.slice/TestFS.mount
Apr 17 16:30:21 testvm1 systemd[1]: Mounting /TestFS...
Apr 17 16:30:21 testvm1 systemd[1]: Mounted /TestFS.
Creazione di un'unità di montaggio
Mount units may be configured either with the traditional /etc/fstab file or with systemd units. Fedora uses the fstab file as it is created during the installation. However, systemd uses the systemd-fstab-generator program to translate the fstab file into systemd units for each entry in the fstab file. Now that you know you can use systemd .mount unit files for filesystem mounting, try it out by creating a mount unit for this filesystem.
First, unmount /TestFS . Edit the /etc/fstab file and delete or comment out the TestFS linea. Now, create a new file with the name TestFS.mount in the /etc/systemd/system directory. Edit it to contain the configuration data below. The unit file name and the name of the mount point must be identical, or the mount will fail:
# This mount unit is for the TestFS filesystem
# By David Both
# Licensed under GPL V2
# This file should be located in the /etc/systemd/system directory
[Unit]
Description=TestFS Mount
[Mount]
What=/dev/mapper/VG01-TestFS
Where=/TestFS
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
The Description line in the [Unit] section is for us humans, and it provides the name that's shown when you list mount units with systemctl -t mount . The data in the [Mount] section of this file contains essentially the same data that would be found in the fstab file.
Now enable the mount unit:
[root@testvm1 etc]# systemctl enable TestFS.mount
Created symlink /etc/systemd/system/multi-user.target.wants/TestFS.mount → /etc/systemd/system/TestFS.mount.
This creates the symlink in the /etc/systemd/system directory, which will cause this mount unit to be mounted on all subsequent boots. The filesystem has not yet been mounted, so you must "start" it:
[root@testvm1 ~]# systemctl start TestFS.mountVerify that the filesystem has been mounted:
[root@testvm1 ~]# systemctl status TestFS.mount
● TestFS.mount - TestFS Mount
Loaded: loaded (/etc/systemd/system/TestFS.mount; enabled; vendor preset: disabled)
Active: active (mounted) since Sat 2020-04-18 09:59:53 EDT; 14s ago
Where: /TestFS
What: /dev/mapper/VG01-TestFS
Tasks: 0 (limit: 19166)
Memory: 76.0K
CPU: 3ms
CGroup: /system.slice/TestFS.mount
Apr 18 09:59:53 testvm1 systemd[1]: Mounting TestFS Mount...
Apr 18 09:59:53 testvm1 systemd[1]: Mounted TestFS Mount.
This experiment has been specifically about creating a unit file for a mount, but it can be applied to other types of unit files as well. The details will be different, but the concepts are the same. Yes, I know it is still easier to add a line to the /etc/fstab file than it is to create a mount unit. But this is a good example of how to create a unit file because systemd does not have generators for every type of unit.
In summary
This article looked at systemd units in more detail and how to use the systemctl command to explore and manage units. It also showed how to stop and disable units and create a new systemd mount unit to mount a new filesystem and enable it to initiate during startup.
In the next article in this series, I will take you through a recent problem I had during startup and show you how I circumvented it using systemd.
Resources
There is a great deal of information about systemd available on the internet, but much is terse, obtuse, or even misleading. In addition to the resources mentioned in this article, the following webpages offer more detailed and reliable information about systemd startup.
- The Fedora Project has a good, practical guide to systemd. It has pretty much everything you need to know in order to configure, manage, and maintain a Fedora computer using systemd.
- The Fedora Project also has a good cheat sheet that cross-references the old SystemV commands to comparable systemd ones.
- For detailed technical information about systemd and the reasons for creating it, check out Freedesktop.org's description of systemd.
- Linux.com's "More systemd fun" offers more advanced systemd information and tips.
There is also a series of deeply technical articles for Linux sysadmins by Lennart Poettering, the designer and primary developer of systemd. These articles were written between April 2010 and September 2011, but they are just as relevant now as they were then. Much of everything else good that has been written about systemd and its ecosystem is based on these papers.
- Rethinking PID 1
- systemd for Administrators, Part I
- systemd for Administrators, Part II
- systemd for Administrators, Part III
- systemd for Administrators, Part IV
- systemd for Administrators, Part V
- systemd for Administrators, Part VI
- systemd for Administrators, Part VII
- systemd for Administrators, Part VIII
- systemd for Administrators, Part IX
- systemd for Administrators, Part X
- systemd for Administrators, Part XI