Parte del compito dell'amministratore di sistema consiste nell'analizzare le prestazioni dei sistemi e nel trovare e risolvere i problemi che causano scarse prestazioni e lunghi tempi di avvio. Gli amministratori di sistema devono anche controllare altri aspetti della configurazione e dell'utilizzo di systemd.
Il sistema systemd init fornisce systemd-analyze strumento che può aiutare a scoprire problemi di prestazioni e altre importanti informazioni di sistema. In un articolo precedente, Analisi del calendario e degli intervalli di tempo di sistema , ho usato systemd-analyze per analizzare timestamp e intervalli di tempo nei timer di sistema, ma questo strumento ha molti altri usi, alcuni dei quali esplorerò in questo articolo.
Panoramica dell'avvio
La sequenza di avvio di Linux è un buon punto di partenza per l'esplorazione perché molti systemd-analyze le funzioni dello strumento sono mirate all'avvio. Ma prima, è importante capire la differenza tra avvio e avvio. La sequenza di avvio inizia con il POST (power-on self test) del BIOS e termina al termine del caricamento del kernel e assume il controllo del sistema host, che è l'inizio dell'avvio e il punto in cui inizia il diario di sistema.
Nel secondo articolo di questa serie, Capire systemd all'avvio su Linux , discuto l'avvio in modo un po' più dettagliato rispetto a ciò che accade e in quale sequenza. In questo articolo, voglio esaminare la sequenza di avvio per esaminare la quantità di tempo necessaria per eseguire l'avvio e quali attività richiedono più tempo.
I risultati che mostrerò di seguito provengono dalla mia workstation principale, che è molto più interessante dei risultati di una macchina virtuale. Questa workstation è composta da una scheda madre ASUS TUF X299 Mark 2, una CPU Intel i9-7960X con 16 core e 32 CPU (thread) e 64 GB di RAM. Alcuni dei comandi seguenti possono essere eseguiti da un utente non root, ma in questo articolo utilizzerò root per evitare di dover passare da un utente all'altro.
Esistono diverse opzioni per esaminare la sequenza di avvio. La forma più semplice di systemd-analyze comando mostra una panoramica della quantità di tempo trascorso in ciascuna delle sezioni principali di avvio, avvio del kernel, caricamento ed esecuzione di initrd (cioè, initial ramdisk, un'immagine di sistema temporanea che viene utilizzata per inizializzare parte dell'hardware e montare il / [root] filesystem) e userspace (dove vengono caricati tutti i programmi e i demoni necessari per portare l'host a uno stato utilizzabile). Se nessun sottocomando viene passato al comando, systemd-analyze time è implicito:
[root@david ~]$ systemd-analyze
Startup finished in 53.921s (firmware) + 2.643s (loader) + 2.236s (kernel) + 4.348s (initrd) + 10.082s (userspace) = 1min 13.233s
graphical.target reached after 10.071s in userspace
[root@david ~]#
Il dato più notevole in questo output è la quantità di tempo trascorso nel firmware (BIOS):quasi 54 secondi. Questa è una quantità straordinaria di tempo e nessuno dei miei altri sistemi fisici impiega così tanto tempo per passare attraverso il BIOS.
Il mio laptop System76 Oryx Pro impiega solo 8.506 secondi nel BIOS e tutti i miei sistemi costruiti in casa impiegano poco meno di 10 secondi. Dopo alcune ricerche online, ho scoperto che questa scheda madre è nota per il suo tempo di avvio del BIOS eccessivamente lungo. La mia scheda madre non "si avvia mai". Si blocca sempre e devo eseguire un ciclo di spegnimento/accensione, quindi il BIOS si avvia con un errore e devo premere F1 per accedere alla configurazione del BIOS, da dove posso selezionare l'unità di avvio e completare l'avvio. Ecco da dove arriva il tempo extra.
Non tutti gli host mostrano i dati del firmware. I miei esperimenti non scientifici mi portano a credere che questi dati siano mostrati solo per i processori Intel di generazione 9 o superiore. Ma potrebbe non essere corretto.
Questa panoramica del processo di avvio dell'avvio è interessante e fornisce informazioni valide (anche se limitate), ma sono disponibili molte più informazioni sull'avvio, come descriverò di seguito.
Assegnare la colpa
Puoi usare systemd-analyze blame per scoprire quali unità di sistema richiedono più tempo per l'inizializzazione. I risultati vengono visualizzati in base al tempo impiegato per l'inizializzazione, dal più al minimo:
[root@david ~]$ systemd-analyze blame
5.417s NetworkManager-wait-online.service
3.423s dracut-initqueue.service
2.715s systemd-udev-settle.service
2.519s fstrim.service
1.275s udisks2.service
1.271s smartd.service
996ms upower.service
637ms lvm2-monitor.service
533ms lvm2-pvscan@8:17.service
520ms dmraid-activation.service
460ms vboxdrv.service
396ms initrd-switch-root.service
<SNIP – removed lots of entries with increasingly small times>
Poiché molti di questi servizi vengono avviati in parallelo, i numeri possono aumentare notevolmente rispetto al totale fornito da systemd-analyze time per tutto dopo il BIOS. Tutti questi sono numeri piccoli, quindi non riesco a trovare risparmi significativi qui.
I dati di questo comando possono fornire indicazioni su quali servizi potresti considerare per migliorare i tempi di avvio. I servizi non utilizzati possono essere disabilitati. Non sembra essere alcun singolo servizio che impiega troppo tempo durante questa sequenza di avvio. Potresti vedere risultati diversi per ogni avvio e avvio.
Catene critiche
Come il percorso critico nella gestione dei progetti, una catena critica mostra la catena di eventi critici dal punto di vista temporale che si verificano durante l'avvio. Queste sono le unità di sistema che vuoi esaminare se l'avvio è lento, poiché sono quelle che causerebbero ritardi. Questo strumento non mostra tutte le unità che iniziano, solo quelle in questa catena di eventi critica:
[root@david ~]# systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @10.071s
└─lxdm.service @10.071s
└─plymouth-quit.service @10.047s +22ms
└─systemd-user-sessions.service @10.031s +7ms
└─remote-fs.target @10.026s
└─remote-fs-pre.target @10.025s
└─nfs-client.target @4.636s
└─gssproxy.service @4.607s +28ms
└─network.target @4.604s
└─NetworkManager.service @4.383s +219ms
└─dbus-broker.service @4.434s +136ms
└─dbus.socket @4.369s
└─sysinit.target @4.354s
└─systemd-update-utmp.service @4.345s +9ms
└─auditd.service @4.301s +42ms
└─systemd-tmpfiles-setup.service @4.254s +42ms
└─import-state.service @4.233s +19ms
└─local-fs.target @4.229s
└─Virtual.mount @4.019s +209ms
└─systemd-fsck@dev-mapper-vg_david2\x2dVirtual.service @3.742s +274ms
└─local-fs-pre.target @3.726s
└─lvm2-monitor.service @356ms +637ms
└─dm-event.socket @319ms
└─-.mount
└─system.slice
└─-.slice
[root@david ~]#
I numeri preceduti da @ mostra il numero assoluto di secondi dall'avvio dell'avvio quando l'unità diventa attiva. I numeri preceduti da + mostra il tempo necessario all'avvio dell'unità.
Stato del sistema
A volte è necessario determinare lo stato corrente del sistema. Il systemd-analyze dump il comando esegue il dump di un massiccio quantità di dati sullo stato corrente del sistema. Inizia con un elenco dei timestamp di avvio primari, un elenco di ciascuna unità systemd e una descrizione completa dello stato di ciascuna:
[root@david ~]# systemd-analyze dump
Timestamp firmware: 1min 7.983523s
Timestamp loader: 3.872325s
Timestamp kernel: Wed 2020-08-26 12:33:35 EDT
Timestamp initrd: Wed 2020-08-26 12:33:38 EDT
Timestamp userspace: Wed 2020-08-26 12:33:42 EDT
Timestamp finish: Wed 2020-08-26 16:33:56 EDT
Timestamp security-start: Wed 2020-08-26 12:33:42 EDT
Timestamp security-finish: Wed 2020-08-26 12:33:42 EDT
Timestamp generators-start: Wed 2020-08-26 16:33:42 EDT
Timestamp generators-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-start: Wed 2020-08-26 16:33:43 EDT
Timestamp units-load-finish: Wed 2020-08-26 16:33:43 EDT
Timestamp initrd-security-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-security-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-generators-finish: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-start: Wed 2020-08-26 12:33:38 EDT
Timestamp initrd-units-load-finish: Wed 2020-08-26 12:33:38 EDT
-> Unit system.slice:
Description: System Slice
Instance: n/a
Unit Load State: loaded
Unit Active State: active
State Change Timestamp: Wed 2020-08-26 12:33:38 EDT
Inactive Exit Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Enter Timestamp: Wed 2020-08-26 12:33:38 EDT
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
May GC: no
<SNIP – Deleted a bazillion lines of output>
Sulla mia workstation principale, questo comando ha generato un flusso di 49.680 righe e circa 1,66 MB. Questo comando è molto veloce, quindi non devi aspettare i risultati.
Più risorse Linux
- Comandi Linux cheat sheet
- Cheat sheet sui comandi avanzati di Linux
- Corso online gratuito:Panoramica tecnica RHEL
- Cheat sheet della rete Linux
- Cheat sheet di SELinux
- Cheat sheet dei comandi comuni di Linux
- Cosa sono i container Linux?
- I nostri ultimi articoli su Linux
Mi piace la ricchezza di dettagli forniti per i vari dispositivi collegati, come lo storage. Ogni unità systemd ha una sezione con dettagli come le modalità per vari runtime, cache e directory di registro, la riga di comando utilizzata per avviare l'unità, l'ID del processo (PID), il timestamp di avvio, nonché limiti di memoria e file.
La pagina man di systemd-analyze mostra il systemd-analyze --user dump opzione, che ha lo scopo di visualizzare informazioni sullo stato interno del gestore utenti. Questo non riesce per me e le ricerche su Internet indicano che potrebbe esserci un problema. In systemd, --user le istanze vengono utilizzate per gestire e controllare le risorse per la gerarchia dei processi appartenenti a ciascun utente. I processi per ogni utente fanno parte di un gruppo di controllo, di cui parlerò in un prossimo articolo.
Grafici analitici
La maggior parte dei capi dai capelli a punta (PHB) e molti buoni manager trovano graziosi grafici più facili da leggere e capire rispetto ai dati sulle prestazioni del sistema basati su testo che di solito preferisco. A volte, però, anche a me piace un buon grafico e systemd-analyze fornisce la capacità di visualizzare i dati di avvio/avvio in un grafico di grafica vettoriale SVG.
Il comando seguente genera un file di grafica vettoriale che visualizza gli eventi che si verificano durante l'avvio e l'avvio. Ci vogliono solo pochi secondi per generare questo file:
[root@david ~]# systemd-analyze plot > /tmp/bootup.svgQuesto comando crea un SVG, che è un file di testo che definisce una serie di vettori grafici che le applicazioni, tra cui Image Viewer, Ristretto, Okular, Eye of Mate, LibreOffice Draw e altri, usano per generare un grafico. Queste applicazioni elaborano i file SVG per creare un'immagine.
Ho usato LibreOffice Draw per eseguire il rendering di un grafico. Il grafico è enorme e devi ingrandire considerevolmente per distinguere qualsiasi dettaglio. Eccone una piccola parte:
La sequenza di avvio è a sinistra dello zero (0) sulla timeline nel grafico e la sequenza di avvio è a destra di zero. Questa piccola porzione mostra il kernel, initrd e i processi initrd iniziato.
Questo grafico mostra a colpo d'occhio cosa è iniziato quando, quanto tempo ci è voluto per l'avvio e le principali dipendenze. Il percorso critico è evidenziato in rosso.
Un altro comando che genera output grafico è systemd-analyze plot . Genera descrizioni dei grafici delle dipendenze testuali in formato DOT. Il flusso di dati risultante viene quindi reindirizzato tramite il dot utility, che fa parte di una famiglia di programmi che possono essere utilizzati per generare file di grafica vettoriale da vari tipi di dati. Questi file SVG possono anche essere elaborati dagli strumenti sopra elencati.
Innanzitutto, genera il file. Ci sono voluti quasi nove minuti sulla mia workstation principale:
[root@david ~]# time systemd-analyze dot | dot -Tsvg > /tmp/test.svg
Color legend: black = Requires
dark blue = Requisite
dark grey = Wants
red = Conflicts
green = After
real 8m37.544s
user 8m35.375s
sys 0m0.070s
[root@david ~]#
Non riprodurrò l'output qui perché il grafico risultante è praticamente spaghetti. Ma dovresti provarlo e visualizzare il risultato per vedere cosa intendo.
Condizionali
Una delle capacità più interessanti, ma alquanto generiche, che ho scoperto durante la lettura di systemd-analyze(1) la pagina man è la condition sottocomando. (Sì, leggo le pagine man ed è incredibile quello che ho imparato in questo modo!) Questa condition il sottocomando può essere utilizzato per testare le condizioni e le asserzioni che possono essere utilizzate nei file di unità di sistema.
Può anche essere utilizzato negli script per valutare una o più condizioni:restituisce uno zero (0) se tutte sono soddisfatte o uno (1) se una qualsiasi condizione non è soddisfatta. In entrambi i casi, vomita anche testo sui suoi risultati.
L'esempio seguente, dalla pagina man, è un po' complesso. Verifica una versione del kernel compresa tra 4.0 e 5.1, che l'host funzioni con alimentazione CA, che l'architettura del sistema sia tutt'altro che ARM e che la directory /etc/os-release esiste. Ho aggiunto echo $? dichiarazione per stampare il codice di ritorno.
[root@david ~]# systemd-analyze condition 'ConditionKernelVersion = ! <4.0' \
'ConditionKernelVersion = >=5.1' \
'ConditionACPower=|false' \
'ConditionArchitecture=|!arm' \
'AssertPathExists=/etc/os-release' ; \
echo $?
test.service: AssertPathExists=/etc/os-release succeeded.
Asserts succeeded.
test.service: ConditionArchitecture=|!arm succeeded.
test.service: ConditionACPower=|false failed.
test.service: ConditionKernelVersion=>=5.1 succeeded.
test.service: ConditionKernelVersion=!<4.0 succeeded.
Conditions succeeded.
0
[root@david ~]#
L'elenco delle condizioni e delle asserzioni inizia intorno alla riga 600 su systemd.unit(5) pagina man.
Elenco dei file di configurazione
La systemd-analyze lo strumento fornisce un modo per inviare il contenuto di vari file di configurazione a STDOUT , come mostrato qui. La directory di base è /etc/ :
[root@david ~]# systemd-analyze cat-config systemd/system/display-manager.service
# /etc/systemd/system/display-manager.service
[Unit]
Description=LXDM (Lightweight X11 Display Manager)
#Documentation=man:lxdm(8)
[email protected]
After=systemd-user-sessions.service [email protected] plymouth-quit.service livesys-late.service
#Conflicts=plymouth-quit.service
[Service]
ExecStart=/usr/sbin/lxdm
Restart=always
IgnoreSIGPIPE=no
#BusName=org.freedesktop.lxdm
[Install]
Alias=display-manager.service
[root@david ~]#
Questo è un sacco di digitazione per fare nient'altro che un cat standard comando fa. Trovo che il comando successivo sia un po' utile. Può cercare file con il modello specificato all'interno delle posizioni di sistema standard:
[root@david ~]# systemctl cat backup*
# /etc/systemd/system/backup.timer
# This timer unit runs the local backup program
# (C) David Both
# Licensed under GPL V2
#
[Unit]
Description=Perform system backups
Requires=backup.service
[Timer]
Unit=backup.service
OnCalendar=*-*-* 00:15:30
[Install]
WantedBy=timers.target
# /etc/systemd/system/backup.service
# This service unit runs the rsbu backup program
# By David Both
# Licensed under GPL V2
#
[Unit]
Description=Backup services using rsbu
Wants=backup.timer
[Service]
Type=oneshot
Environment="HOME=/root"
ExecStart=/usr/local/bin/rsbu -bvd1
ExecStart=/usr/local/bin/rsbu -buvd2
[Install]
WantedBy=multi-user.target
[root@david ~]#
Entrambi questi comandi premettono il contenuto di ciascun file con una riga di commento contenente il percorso completo e il nome del file.
Verifica file unitario
Dopo aver creato un nuovo file unit, può essere utile verificare che la sua sintassi sia corretta. Questo è ciò che il verify il sottocomando lo fa. Può elencare le direttive che sono scritte in modo errato e richiamare le unità di servizio mancanti:
[root@david ~]# systemd-analyze verify /etc/systemd/system/backup.serviceAderendo alla filosofia Unix/Linux secondo cui "il silenzio è d'oro", la mancanza di messaggi di output significa che non ci sono errori nel file scansionato.
Sicurezza
La security il sottocomando controlla il livello di sicurezza dei servizi specificati. Funziona solo su unità di servizio e non su altri tipi di file di unità:
[root@david ~]# systemd-analyze security display-manager
NAME DESCRIPTION >
✗ PrivateNetwork= Service has access to the host's network >
✗ User=/DynamicUser= Service runs as root user >
✗ CapabilityBoundingSet=~CAP_SET(UID|GID|PCAP) Service may change UID/GID identities/capabilities >
✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service has administrator privileges >
✗ CapabilityBoundingSet=~CAP_SYS_PTRACE Service has ptrace() debugging abilities >
✗ RestrictAddressFamilies=~AF_(INET|INET6) Service may allocate Internet sockets >
✗ RestrictNamespaces=~CLONE_NEWUSER Service may create user namespaces >
✗ RestrictAddressFamilies=~… Service may allocate exotic sockets >
✗ CapabilityBoundingSet=~CAP_(CHOWN|FSETID|SETFCAP) Service may change file ownership/access mode/capabilities unres>
✗ CapabilityBoundingSet=~CAP_(DAC_*|FOWNER|IPC_OWNER) Service may override UNIX file/IPC permission checks >
✗ CapabilityBoundingSet=~CAP_NET_ADMIN Service has network configuration privileges >
✗ CapabilityBoundingSet=~CAP_SYS_MODULE Service may load kernel modules
<SNIP>
✗ CapabilityBoundingSet=~CAP_SYS_TTY_CONFIG Service may issue vhangup() >
✗ CapabilityBoundingSet=~CAP_WAKE_ALARM Service may program timers that wake up the system >
✗ RestrictAddressFamilies=~AF_UNIX Service may allocate local sockets >
→ Overall exposure level for backup.service: 9.6 UNSAFE ?
lines 34-81/81 (END)
Sì, l'emoji fa parte dell'output. Ma, naturalmente, molti servizi richiedono un accesso praticamente completo a tutto per poter svolgere il proprio lavoro. Ho eseguito questo programma su diversi servizi, incluso il mio servizio di backup; i risultati possono differire, ma la linea di fondo sembra essere per lo più la stessa.
Questo strumento sarebbe molto utile per controllare e riparare le unità di servizio dello spazio utente in ambienti critici per la sicurezza. Non credo che abbia molto da offrire per la maggior parte di noi.
Pensieri finali
Questo potente strumento offre alcune opzioni interessanti e incredibilmente utili. Gran parte di ciò che esplora questo articolo riguarda l'uso di systemd-analyze per fornire informazioni dettagliate sulle prestazioni di avvio di Linux utilizzando systemd. Può anche analizzare altri aspetti di systemd.
Alcuni di questi strumenti sono di uso limitato e un paio dovrebbero essere completamente dimenticati. Ma la maggior parte può essere utilizzata con buoni risultati quando si risolvono problemi con l'avvio e altre funzioni di sistema.
Risorse
Ci sono molte informazioni su systemd disponibili su Internet, ma molte sono concise, ottuse o addirittura fuorvianti. Oltre alle risorse menzionate in questo articolo, le seguenti pagine Web offrono informazioni più dettagliate e affidabili sull'avvio di systemd. Questo elenco è cresciuto da quando ho iniziato questa serie di articoli per riflettere la ricerca che ho fatto.
- La pagina di manuale di systemd.unit(5) contiene un bell'elenco di sezioni di file di unità e le relative opzioni di configurazione insieme a descrizioni concise di ciascuna.
- Il progetto Fedora ha una buona guida pratica a systemd. Ha praticamente tutto ciò che devi sapere per configurare, gestire e mantenere un computer Fedora usando systemd.
- Il progetto Fedora ha anche un buon cheat sheet che incrocia i vecchi comandi SystemV con quelli di systemd comparabili.
- La documentazione di Red Hat contiene una buona descrizione della struttura dei file Unit e altre informazioni importanti.
- Per informazioni tecniche dettagliate su systemd e sui motivi della sua creazione, consulta la descrizione di systemd di Freedesktop.org.
- "Più divertimento di sistema" di Linux.com offre informazioni e suggerimenti più avanzati sul sistema.
C'è anche una serie di articoli profondamente tecnici per gli amministratori di sistema Linux di Lennart Poettering, il designer e sviluppatore principale di systemd. Questi articoli sono stati scritti tra aprile 2010 e settembre 2011, ma sono rilevanti ora come allora. Gran parte di tutto ciò che è stato scritto di buono su systemd e il suo ecosistema si basa su questi documenti.
- Ripensare il PID 1
- systemd per amministratori, parte I
- sistema per amministratori, parte II
- sistema per amministratori, parte III
- systemd per amministratori, parte IV
- sistema per amministratori, parte V
- sistema per amministratori, parte VI
- sistema per amministratori, parte VII
- systemd per amministratori, parte VIII
- systemd per amministratori, parte IX
- sistema per amministratori, parte X
- systemd per amministratori, parte XI