Segui ZDNET: Aggiungici come fonte preferita su Google.
I principali punti salienti di ZDNET
- Se l’avvio della tua macchina Linux è lento, prova questo strumento.
- Systemd-analyze offre numerous opzioni per aiutare.
- Qualsiasi macchina Linux che supporta Systemd avrà questi.
Linux ha un sacco di strumenti utili che possono aiutarti a scoprire cose giuste, cose sbagliate e tutto il resto. Puoi personalizzarlo a tuo piacimento o lasciarlo così com’è.
Advert un certo punto, potresti essere curioso di sapere cosa sta rallentando il tempo di avvio della tua macchina Linux. Anche se potrebbe sembrare un compito difficile, rimarrai sorpreso da quanto sia in realtà facile. In effetti, Linux ha uno strumento integrato per aiutarti a fare proprio questo.
Inoltre: come scegliere la distribuzione desktop Linux giusta per te
Se la tua distribuzione Linux utilizza il sistema systemd init, hai già ciò che ti serve per risolvere il problema dei tempi di avvio lenti e ti mostrerò come utilizzare lo strumento.
systemd-analyze
Lo strumento in questione fa parte del sistema systemd init e si chiama systemd-analyze. Ciò che fa questo strumento è analizzare ed eseguire il debug del gestore di inizializzazione in Linux.
Se dovessi semplicemente eseguire il comando systemd-analyzevedresti risultati simili a questi:
L’avvio è terminato in 6.669 s (kernel) + 30.368 s (spazio utente) = 37.037 s
graphic.goal raggiunto dopo 27.479 s nello spazio utente
Come puoi vedere sopra, il tempo di avvio totale per una delle mie macchine è di 37.037 secondi, di cui 6.669 per il kernel e 30.368 secondi per le app in spazio utente. Poi c’è il graphic.goal raggiunto (la schermata di accesso) a 27.479 secondi.
Anche: 8 cose che puoi fare con Linux che non puoi fare con MacOS o Home windows
Queste sono informazioni piuttosto buone, ma non ci aiutano molto. La buona notizia è che ci sono alcune opzioni importanti che possiamo utilizzare per aiutarci a capire cosa sta succedendo.
colpa
La prima opzione è colpa, che elenca tutti i file di unità systemd, mostrando il tempo impiegato da ciascuna unità per inizializzarsi durante l’ultimo avvio, dal più lungo al più breve. L’opzione colpa è utile per identificare quali servizi causano ritardi nell’avvio.
L’opzione colpa viene utilizzata in questo modo:
analizzare la colpa tramite systemd
I risultati saranno simili a questi:
57.158s apt-daily.service
20.879s apt-daily-upgrade.service
17.609s servizio snapd
10.647s docker.service
7.217s snapd.seeded.service
4.772s fstrim.service
4.160s dev-sda2.gadget
3.824s motd-news.service
3.756s cloud-init-local.service
3.369s cloud-config.service
3.173s snap.lxd.activate.service
2.932s containerd.service
2.877s cloud-final.service
2.677s systemd-udev-settle.service
2.498s cloud-init.service
2.125s networkd-dispatcher.service
2.051s man-db.service
Come puoi vedere, apt-daily.service è l’unità systemd che impiega più tempo. Cos’è quell’unità? L’unità apt-daily.service è responsabile del controllo automatico quotidiano degli aggiornamenti software program sulle distribuzioni Linux basate su Debian.
Anche: Il motivo più importante per cui dovresti usare Linux a casa
Anche se puoi interrompere apt-daily.service, non lo consiglierei. Puoi consultare l’elenco generato da systemd-analyze beast e vedere se ci sono servizi che puoi disabilitare in modo affidabile e sicuro per accelerare i tempi di avvio.
catena critica
L’opzione critical-chain mostra la catena di unità che ha rallentato in modo critico il processo di avvio. Questa opzione aiuta a individuare i colli di bottiglia nella catena delle dipendenze. Nell’output, l’ora in cui un’unità diventa attiva viene stampata dopo il carattere @, e il tempo impiegato dall’unità per avviarsi viene stampato dopo il carattere +.
L’output per la catena critica è simile al seguente:
graphic.goal @27.479s
└─multi-utente.goal @27.478s
└─docker.service @16.830s +10.647s
└─containerd.service @13.891s +2.932s
└─dbus.service @13.869s
└─primary.goal @13.796s
└─sockets.goal @13.794s
└─snapd.socket @13.745s +44ms
└─sysinit.goal @13.659s
└─cloud-init.service @11.149s +2.498s
└─systemd-networkd-wait-online.service @10.024s +1.118s
└─systemd-networkd.service @9.838s +180ms
└─network-pre.goal @9.832s
└─cloud-init-local.service @6.073s +3.756s
└─systemd-remount-fs.service @1.434s +174ms
└─systemd-journald.socket @1.147s
└─system.slice @1.067s
└─-.slice @1.067s
Come puoi vedere, i due servizi che potrebbero causare colli di bottiglia su questo sistema (una macchina Ubuntu Server) sono docker.service e containerd.service. Se volessi accelerare il tempo di avvio, potrei disabilitare questi servizi all’avvio e avviarli manualmente.
complotto
Infine, abbiamo plot, che genera un file .svg (Scalable Vector Graphic) che rappresenta visivamente il processo di avvio e le dipendenze affiliate. Una volta generato il file, puoi aprirlo in un browser Net o in un visualizzatore di immagini che supporti i file SVG.
Il comando per questo è simile a:
systemd-analyze plot > boot.svg
Troverai quindi il file .svg nella listing di lavoro corrente. Suggerirei di aprire il file in un browser Net poiché la maggior parte dei browser Net supporta il formato file e l’immagine può essere piuttosto grande.
Il file immagine può essere enorme.
Jack Wallen/ZDNET
Anche: Come eseguire un’app Home windows su Linux con Wine
Come puoi vedere dal mio esempio, circa 18 secondi è il momento in cui la maggior parte delle applicazioni e dei servizi inizia advert inizializzarsi.
Lo strumento systemd-analyze è comodo da avere a portata di mano. Con esso, puoi iniziare a risolvere i problemi che causano l’avvio del sistema più lentamente del previsto.
