GNU/Linux >> Linux Esercitazione >  >> Linux

Utilizzo del comando systemctl per gestire le unità systemd

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 sysstat

sysstat 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-files

Puoi 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 service

La 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 mount

Questo 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 2

Ora 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.mount

Verify 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

Linux
  1. Un'introduzione all'uso di tcpdump nella riga di comando di Linux

  2. Gestisci l'avvio usando systemd

  3. Usando la forza sulla riga di comando di Linux

  4. Come gestire le unità systemd all'avvio

  5. Usando –exclude con il comando Du?

Conosci il tuo sistema (usando la riga di comando)

Comandi Systemctl per gestire il servizio Systemd

Utilizzo del comando GREP in Linux con esempi

Principianti Linux:gestisci i file utilizzando il terminale su CentOS 8

Tutorial sull'uso del comando Timeout su Linux

Tutorial sull'utilizzo dell'ultimo comando nel terminale Linux