Creazione di profili di avvio con systemd-analyze in Linux

Se hai mai pensato che il tuo Linux Ci vuole "metà della vita" per avviarlo, oppure sei semplicemente curioso di sapere cosa succede dal momento in cui premi il pulsante di accensione fino a quando non vedi il desktop, systemd-analyze è lo strumento perfetto per spiare l'avvio del tuo sistema.Non è necessario essere un amministratore di sistema professionista per trarne vantaggio: con pochi comandi e un po' di buon senso è possibile capire cosa sta succedendo e, se necessario, ridurre di diversi secondi l'orario di avvio.

In molti forum e comunità, le persone condividono i loro orari di inizio come se fossero record sportivi, ma al di là della competizione amichevole, Misurare e comprendere il processo di avvio con systemd-analyze è utile per rilevare errori, servizi non configurati correttamente e colli di bottiglia.Diamo un'occhiata più da vicino a cosa offre questo strumento, come interpretarne i risultati e quali modifiche sono sensate per ottimizzare la startup senza compromettere nulla di importante.

Che cos'è systemd-analyze e perché dovrebbe interessarti?

systemd-analyze è un'utilità inclusa in systemd che viene utilizzata per analizzare le prestazioni di avvio nei sistemi GNU/Linux.Viene utilizzato da distribuzioni come Debian, Ubuntu, Fedora, openSUSE, Arch, Manjaro e molte altre, a patto che systemd sia il sistema init.

Con questo strumento puoi Visualizza sia una panoramica globale del tempo di avvio sia una ripartizione molto dettagliata per servizi, dispositivi, socket e punti di montaggio.Inoltre, consente di generare grafici in formato SVG, visualizzare catene di dipendenze critiche e ottenere dati in altri formati come JSON o tabelle.

Sebbene systemd-analyze abbia parecchie opzioni, Per la maggior parte degli utenti, alcuni comandi sono fondamentali: time, blame, critical-chain e plotDa lì puoi decidere quali servizi esaminare, quali unità disattivare e quali problemi analizzare più a fondo.

Panoramica rapida del processo di avvio su un PC Linux

Prima di iniziare a guardare i numeri, è utile avere un'idea generale di le fasi di avvio di un computer fino all'entrata in gioco di systemdCiò aiuta molto a interpretare quale porzione di tempo corrisponde al kernel, all'initrd o allo spazio utente, che systemd-analyze mostrerà.

Il primo è il file accensione fisicaL'alimentatore converte la corrente alternata in corrente continua adatta e la scheda madre distribuisce tensioni e amperaggi tra CPU, RAM, dischi rigidi, ecc. Quindi il famoso firmware, o il BIOS UEFI classico o moderno, che risiede in una ROM sulla scheda.

In questa fase del firmware viene eseguito quanto segue: POST (Power On Self Test), che controlla la memoria, la tastiera, i controller, i dischi e altri dispositivi di baseInoltre, è lì che viene presa la decisione. ordine di avvio: disco, USBDVD, rete, ecc. La configurazione "personalizzabile" viene salvata in una piccola memoria CMOS alimentata dalla batteria a bottone della scheda madre.

Una volta rilevato il dispositivo di avvio, il firmware cerca il settore di avvio (MBR o partizione EFI) e passa il controllo al boot manager, che in Linux è solitamente GRUBGRUB carica la sua configurazione (solitamente da /boot/grub/grub.cfg), visualizza il menu (timeout del menu di avvio) e, quando si scelgono sistema e kernel, inizia la fase successiva.

In quel momento il boot manager si carica l'immagine del kernel (vmlinuz) e l'ambiente di avvio iniziale, l'initramfs, che contiene un "mini-Linux" con tutto ciò che serve per rilevare dischi, moduli e il file system di rootL'immagine viene caricata nella RAM, monta la root finale e infine esegue il processo init con PID 1.

Oggi, nella maggior parte dei sistemi di distribuzione, Il PID 1 è occupato da systemd, che è responsabile dell'avvio dei servizi, del montaggio dei file system, della preparazione dell'ambiente utente e, infine, dell'avvio di Display Manager e del desktop.È proprio questa parte, da quando systemd si avvia fino a quando il sistema è "utilizzabile", che possiamo misurare in modo molto dettagliato grazie a systemd-analyze.

systemd-analyze time: il tempo totale di avvio

El comando più semplice E quello che di solito viene usato per primo è semplicemente:

Correre: systemd-analyze

Puoi anche usare:

Esempio di output:
Startup finished in 0.912s (kernel) + 0.731s (initrd) + 1.485s (userspace) = 3.129s

Con questo riassunto, È possibile vedere direttamente quanto tempo impiega il kernel, quanto tempo impiega initrd e quanto tempo impiega la parte dello spazio utente gestita da systemd.In alcune distribuzioni (ad esempio, alcune Debian/Ubuntu) initrd non appare separatamente e la sua temporizzazione viene aggiunta al kernel.

Questi dati generali servono come riferimento e per il confronto dopo aver apportato modifiche. È abbastanza comune vedere sistemi con vecchie unità HDD che si muovono tra 20 e 60 secondi, e sistemi con SSD quelli moderni che impiegano circa 3-10 secondi, sempre a seconda di quanti servizi sono caricati.

systemd-analyze blame: chi sta ritardando l'avvio

Quando vogliamo entrare nei dettagli, il prossimo passo logico è:

comando: systemd-analyze blame

Con questo comando, systemd-analyze visualizza un elenco di tutte le unità (servizi, mount, dispositivi, socket) ordinate dal tempo di inizializzazione più lungo a quello più breveQualcosa del tipo:

5.678s NetworkManager-wait-online.service
3.210s dev-sda1.device
2.345s snapd.service
...

Questa lista è preziosa per scoprire cosa sta "rubando" secondi. Ora, Bisogna prestare attenzione quando si interpreta il risultato, perché un servizio può sembrare lento semplicemente perché dipende da un altro servizio che impiega del tempo per essere pronto.Il colpevole non è sempre colui che ha più secondi davanti a sé.

Filtraggio rapido: Se vuoi vedere solo i peggiori, puoi combinarlo con strumenti di filtraggio, ad esempio:

Esempio: systemd-analyze blame | head

o in alcune guide è scritto in linea come "systemd-analyze blame | head -n 10". In ogni caso, L'approccio più comune è quello di rivedere gli elementi iniziali e chiedersi se è davvero necessario che siano attivi o se esistono alternative che richiedono meno risorse..

systemd-analyze critical-chain: la catena di avvio critica

Un'altra visione molto interessante è quella catena critica, che si ottiene con:

comando: systemd-analyze critical-chain

L'uscita si presenta come un albero in cui Mostra quali unità formano il percorso più lento verso l'obiettivo principale (per impostazione predefinita il target grafico o multiutente), mostrando per ciascuna quanto tempo impiega e quando inizia. Ad esempio:

graphical.target @12.345s
└─multi-user.target @12.345s
└─NetworkManager-wait-online.service @7.000s +5.345s
└─NetworkManager.service @2.000s +1.234s
...

In questo tipo di uscita, Il tempo che appare dopo "@" indica quando l'unità è stata raggiunta, mentre quello che segue "+" è la durata del suo avvio.Ancora una volta, è opportuno ricordare che, a causa delle dipendenze e dell'esecuzione parallela, alcune cifre potrebbero apparire fuorvianti a prima vista.

Inoltre, esiste la possibilità di chiamare critical-chain specificando un'unità particolare, ad esempio:

systemd-analyze critical-chain NetworkManager.service

Con questo, Si ottiene la catena critica relativa a quella specifica unità, utile quando si indagano i ritardi in un servizio specifico..

systemd-analyze plot: grafico SVG del processo di avvio

Se preferisci qualcosa di più visivo, puoi generare una grafica SVG con:

Esempio: systemd-analyze plot > boot_analysis.svg

o nomi simili come imagen.svg, arranque.svg o 0-graficocarga.svg. Il file SVG generato contiene un grafico a barre che rappresenta il tempo impiegato da ciascuna unità per avviarsi, mostrando anche sovrapposizioni e dipendenze..

Puoi aprire questo grafico con un editor di grafica vettoriale come Inkscape, con GIMP o semplicemente con un browser web modernoÈ particolarmente utile per capire a colpo d'occhio quale parte della startup è più congestionata e dove potrebbe esserci spazio per eseguire le cose in parallelo.

Elenca i servizi abilitati e altri strumenti correlati

Oltre a systemd-analyze, È comune integrare l'analisi utilizzando systemctl per elencare le unità abilitate e il loro stato. Ad esempio:

Esempio: systemctl list-unit-files --state=enabled

Esempio: systemctl list-unit-files --type=service | grep enabled

Così, Puoi individuare i servizi che non utilizzi (ad esempio ModemManager, Bluetooth se non lo usi, servizi di posta elettronica come Postfix, ecc.) e valutare di disattivarli..

Comandi comuni:

• Disabilitare un servizio in modo che non venga avviato con il sistema:
  systemctl disable nombre.service
• Riattivalo all'avvio:
  systemctl enable nombre.service
• Interrompilo nella sessione corrente:
  systemctl stop nombre.service
• Avvialo manualmente:
  systemctl start nombre.service
• Per mascherarlo in modo da evitare che si avvii in qualsiasi modo:
  systemctl mask nombre.service

Negli ambienti grafici sono presenti anche strumenti come systemadm (systemd System Manager, dal pacchetto systemd-ui), il modulo systemd-kcm per KDE Plasma o il gestore dei servizi YaST in openSUSEConsentono di visualizzare lo stato delle unità e di attivare o disattivare i servizi senza toccare la console.

Visualizza messaggi ed errori durante l'avvio

Oltre a systemd-analyze, è utile sapere che Durante l'avvio è possibile nascondere lo "splash" grafico e visualizzare i messaggi in formato testo premendo il tasto freccia giùDi solito vedrai delle righe con la scritta "OK" in verde e, se qualcosa va storto, dei messaggi "FAILED" o degli avvisi con dei contatori di tempo.

Messaggi tipici:

Esempio:
A start job is running for wicked managed network interfaces (x s / no limit)
A start job is running for ModemManager.service (x s / 1min 30s)

indica quello systemd attende che un'unità termini l'avvio o raggiunga un determinato stato, il che può causare ritardi considerevoli.La cosa normale da fare è quindi cercare il nome di quell'unità utilizzando systemd-analyze e systemctl per vedere cosa sta succedendo.

la consultazione: Una volta avviato il sistema, è possibile controllare il registro dell'ultima sessione con:

Esempio: journalctl -b

e così Visualizza errori, avvisi o tempi anomali relativi a servizi specifici.

Esempi concreti di ottimizzazione delle startup

In pratica, alcuni utenti sono passati da tempi di avvio prossimi al minuto o addirittura superiori ai 40 secondi a valori molto ragionevoli dopo alcune regolazioni. Nei sistemi dotati di HDD, il tempo è stato ridotto da oltre 40 secondi a circa 18 secondi semplicemente disabilitando i servizi non necessari e regolando la gestione della rete..

Azioni che hanno aiutato: Ecco alcuni esempi concreti di azioni che hanno contribuito a migliorare i tempi, come "Avvio completato in 880 ms (kernel) + 750 ms (initrd) + 1.148 s (spazio utente) = 2.780 s":

• Disattivare NetworkManager-wait-online.service quando non sono necessari servizi che dipendono dalla rete fin dall'inizio.impedendo al sistema di attendere la connettività.
• Cambiare il gestore di rete da Wicked a NetworkManager in openSUSE in modo che alcune operazioni di rete vengano eseguite in seguito, sul desktop..
• Disattivare i servizi che non hanno senso su quella macchina, come btrfsmaintenance se Btrfs non viene utilizzato, ModemManager se non c'è un modem o Postfix se non viene inviata posta da quella macchina. radice.
• In alcuni casi specifici, regolare lo scheduler I/O del disco (mq-deadline, noop/none per NVMe, ecc.) e rivedere le opzioni SSD..

Anche i dettagli di configurazione come i seguenti hanno un impatto:

• Utilizzare l'opzione di compressione "cat" in /etc/mkinitcpio.conf (sulle distribuzioni di tipo Arch/Manjaro) per creare un initramfs più leggero o più veloce da decomprimere, a seconda dell'hardware..
• Sostituisci il gancio udev con systemd in mkinitcpio per rendere la fase initrd più efficiente con le capacità di systemd.
• Regolare i parametri del kernel come libahci.ignore_sss=1 in GRUB per determinati controller SATA, quando consigliato per l'hardware.

In alcune apparecchiature moderne è stato addirittura raggiunto Ridurre i tempi di avvio dai 7-8 secondi iniziali a circa 3 secondi apportando piccole modifiche: disabilitando i servizi, ottimizzando initramfs e perfezionando le opzioni. immagazzinamentoTuttavia, non è mai una buona idea copiare le impostazioni di un altro utente senza comprenderle, perché ciò che funziona perfettamente per una persona potrebbe danneggiare metà del sistema di un'altra.

Suggerimenti per decidere cosa giocare e cosa non giocare

Grazie a tutte le informazioni fornite da systemd-analyze e systemctl, dovresti essere in grado di rilevare le unità che sembrano causare ritardi. Prima di iniziare a disattivare cose come se non ci fosse un domani, è una buona idea cercare informazioni specifiche sul servizio, sulla tua distribuzione e sulla tua versione specifica..

Linee guida: Alcune linee guida sensate sono:

• Controlla se la versione della distribuzione è in fase di test o è molto recenteA volte il problema è semplicemente un bug che verrà risolto con aggiornamenti successivi.
• Valutare se la lentezza è "normale" su quella distribuzione e su quell'hardware; un certo desktop o un certo insieme di servizi potrebbero essere intrinsecamente più pesanti.
• Identifica i servizi che sono chiaramente superflui nel tuo caso d'uso: ModemManager, daemon di posta, servizi di stampa quando non hai una stampante, daemon di monitoraggio che non usi, ecc.
• Controlla se qualche software aggiuntivo installato esegue il proprio servizio di avvio (ad esempio, ClamAV, ClamTK, hddtemp, schermate di benvenuto personalizzate) e se vale la pena avviarlo dall'inizio..
• Quando si verificano ritardi associati alle unità disco (messaggi come "Un processo di avvio è in esecuzione per dev-disk-by...")Controllare la configurazione di fstab o i montaggi automatici, perché a volte il problema è un dispositivo che non esiste più o un percorso errato.

In molti casi la soluzione non è disattivare il servizio, ma Correggere la causa sottostante (ad esempio, una schermata di benvenuto non ufficiale che rallenta il gestore del display o una connessione di rete configurata in modo errato che fa attendere il gestore indefinitamente).

Impatto dei servizi di rete e VPN sull'avvio

In ambienti in cui l'apparecchiatura deve connettersi a Internet o a una rete privata prima di essere "pronta" (automazione di uffici remoti, server, apparecchiature aziendali), servizi di rete e VPN Possono svolgere un ruolo importante nei tempi di avvio.

Utilizzando systemd-analyze blame si chiarisce se, ad esempio, NetworkManager-wait-online.service, i servizi VPN come OpenVPN, WireGuard o OpenConnect stanno introducendo ritardi significativi.Ecco alcuni consigli pratici:

• Evitare configurazioni che bloccano l'avvio attendendo password interattiveAd esempio, certificati OpenVPN con passphrase senza alcun agente chiave che li gestisca.
• Assicurarsi che i servizi VPN si basino su network-online-target ma non bloccare inutilmente altri servizi che non richiedono connettività immediata.
• Nel caso di WireGuard, mantieni le unità wg-quick@ configurate correttamente ed evita script PostUp/PreDown eccessivamente complessi che rallentano l'avvio..
• Per OpenConnect, utilizzare unità Type=simple ben definite, evitando stringhe di script non necessarie che possono aumentare il tempo di avvio..

Tutto questo può essere facilmente misurato rieseguendo il test. Esegui `systemd-analyze time` e `blame` dopo ogni modifica, così potrai vedere se hai effettivamente ottenuto qualcosa o se hai semplicemente risolto il problema..

Applicazioni grafiche e altri aiuti

Alternative grafiche: Se non hai voglia di combattere costantemente con il terminaleEsistono diverse interfacce grafiche che si basano su systemd e possono aiutarti a gestire l'avvio e lo stato dell'unità senza dover digitare troppi comandi.

• Systemadm (gestore di sistema systemd)Viene installato con il pacchetto systemd-ui su molte distribuzioni e compare nel menu come strumento di amministrazione del sistema. Permette di visualizzare le unità, il loro stato e di abilitarle o disabilitarle.
• systemd-kcm: Modulo di configurazione per KDE Plasma 5 (pacchetto kde-config-systemd). Si integra in "Preferenze di Sistema" > "Amministrazione di Sistema" e visualizza unità di misura, orari e stati.
• Amministratore del servizio YaST su openSUSE: un'interfaccia molto potente per visualizzare i servizi, abilitarli, disabilitarli e regolarne il comportamento all'avvio.

Questi strumenti Sono utili per gli utenti desktop che vogliono semplicemente controllare cosa si sta avviando e disabilitare qualcosa di specifico senza entrare troppo nei dettagli sui file .service.Per modifiche più precise (ad esempio, modificando direttive come After=, Wants= o TimeoutStartSec=) si consiglia comunque di modificare o sovrascrivere le unità tramite /etc/systemd/system.