systemd, sì, tutto in minuscolo, anche all'inizio di una frase, è il moderno sostituto degli script init e SystemV init. È anche molto di più.
Come la maggior parte degli amministratori di sistema, quando penso al programma init e a SystemV, penso all'avvio e all'arresto di Linux e non a molto altro, come la gestione dei servizi una volta che sono attivi e funzionanti. Come init, systemd è la madre di tutti i processi ed è responsabile di portare l'host Linux a uno stato in cui è possibile svolgere un lavoro produttivo. Alcune delle funzioni assunte da systemd, che è molto più esteso del vecchio programma init, sono la gestione di molti aspetti di un host Linux in esecuzione, incluso il montaggio dei filesystem, la gestione dell'hardware, la gestione dei timer e l'avvio e la gestione dei servizi di sistema richiesti avere un host Linux produttivo.
Questa serie di articoli, che si basa in parte su estratti del mio corso di formazione su Linux in tre volumi, Uso e amministrazione di Linux:zero to sysadmin , esplora le funzioni di systemd sia all'avvio che all'inizio al termine dell'avvio.
Avvio Linux
Il processo completo che porta un host Linux da uno stato off a uno stato in esecuzione è complesso, ma è aperto e conoscibile. Prima di entrare nei dettagli, fornirò una rapida panoramica da quando l'hardware host viene acceso fino a quando il sistema è pronto per l'accesso di un utente. Il più delle volte, il "processo di avvio" viene discusso come un'unica entità, ma non è esatto. Ci sono, infatti, tre parti principali del processo di avvio e avvio completo:
- Avvio hardware: Inizializza l'hardware del sistema
- Avvio Linux: Carica il kernel Linux e quindi systemd
- Avvio Linux: Dove systemd prepara l'host per il lavoro produttivo
La sequenza di avvio di Linux inizia dopo che il kernel ha caricato init o systemd, a seconda che la distribuzione utilizzi rispettivamente il vecchio o il nuovo avvio. I programmi init e systemd avviano e gestiscono tutti gli altri processi e sono entrambi conosciuti come la "madre di tutti i processi" sui rispettivi sistemi.
È importante separare l'avvio hardware dall'avvio Linux dall'avvio Linux e definire esplicitamente i punti di demarcazione tra di loro. Comprendere queste differenze e il ruolo che ciascuna gioca nel portare un sistema Linux in uno stato in cui può essere produttivo rende possibile gestire questi processi e determinare meglio dove si verifica un problema durante ciò che la maggior parte delle persone chiama "avvio".
Il processo di avvio segue il processo di avvio in tre fasi e porta il computer Linux a uno stato operativo in cui è utilizzabile per il lavoro produttivo. Il processo di avvio inizia quando il kernel trasferisce il controllo dell'host a systemd.
controversia sul sistema
systemd può evocare un'ampia gamma di reazioni da parte degli amministratori di sistema e di altri responsabili del mantenimento e dell'esecuzione dei sistemi Linux. Il fatto che systemd stia assumendo così tante attività in molti sistemi Linux ha generato respingimento e discordia tra alcuni gruppi di sviluppatori e amministratori di sistema.
SystemV e systemd sono due metodi diversi per eseguire la sequenza di avvio di Linux. Gli script di avvio di SystemV e il programma init sono i vecchi metodi e systemd using target è il nuovo metodo. Sebbene la maggior parte delle moderne distribuzioni Linux utilizzi il nuovo systemd per l'avvio, l'arresto e la gestione dei processi, ce ne sono ancora alcune che non lo fanno. Uno dei motivi è che alcuni manutentori della distribuzione e alcuni amministratori di sistema preferiscono il vecchio metodo SystemV al più recente systemd.
Penso che entrambi abbiano dei vantaggi.
Perché preferisco SystemV
Preferisco SystemV perché è più aperto. L'avvio viene eseguito utilizzando gli script Bash. Dopo che il kernel ha avviato il programma init, che è un binario compilato, init lancia rc.sysinit script, che esegue molte attività di inizializzazione del sistema. Dopo rc.sysinit completa, init avvia /etc/rc.d/rc script, che a sua volta avvia i vari servizi definiti dagli script di avvio di SystemV in /etc/rc.d/rcX.d , dove "X" è il numero del runlevel avviato.
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
Fatta eccezione per il programma init stesso, tutti questi programmi sono script aperti e facilmente conoscibili. È possibile leggere questi script e apprendere esattamente cosa sta accadendo durante l'intero processo di avvio, ma non credo che molti amministratori di sistema lo facciano effettivamente. Ogni script di avvio è numerato in modo che avvii il servizio previsto in una sequenza specifica. I servizi vengono avviati in serie e viene avviato un solo servizio alla volta.
systemd, sviluppato da Lennart Poettering e Kay Sievers di Red Hat, è un sistema complesso di grandi eseguibili binari compilati che non sono comprensibili senza l'accesso al codice sorgente. È open source, quindi "l'accesso al codice sorgente" non è difficile, solo meno conveniente. systemd sembra rappresentare una significativa confutazione di molteplici principi della filosofia Linux. In quanto binario, systemd non è direttamente aperto per consentire all'amministratore di sistema di visualizzare o apportare modifiche semplici. systemd tenta di fare qualsiasi cosa, come la gestione dei servizi in esecuzione, fornendo al contempo molte più informazioni sullo stato rispetto a SystemV. Gestisce anche hardware, processi e gruppi di processi, montaggi di filesystem e molto altro. systemd è presente in quasi ogni aspetto del moderno host Linux, rendendolo lo strumento unico per la gestione del sistema. Tutto ciò è una chiara violazione dei principi secondo cui i programmi dovrebbero essere piccoli e che ogni programma dovrebbe fare una cosa e farla bene.
Perché preferisco systemd
Preferisco systemd come meccanismo di avvio perché avvia il maggior numero possibile di servizi in parallelo, a seconda della fase corrente del processo di avvio. Ciò velocizza l'avvio generale e porta il sistema host a una schermata di accesso più veloce di SystemV.
systemd gestisce quasi ogni aspetto di un sistema Linux in esecuzione. Può gestire i servizi in esecuzione fornendo allo stesso tempo molte più informazioni sullo stato rispetto a SystemV. Gestisce anche hardware, processi e gruppi di processi, montaggi di filesystem e molto altro. systemd è presente in quasi ogni aspetto del moderno sistema operativo Linux, rendendolo lo strumento unico per la gestione del sistema. (Ti suona familiare?)
Gli strumenti di sistema sono binari compilati, ma la suite di strumenti è aperta perché tutti i file di configurazione sono file di testo ASCII. La configurazione di avvio può essere modificata tramite vari strumenti della GUI e della riga di comando, nonché aggiungendo o modificando vari file di configurazione per soddisfare le esigenze dell'ambiente informatico locale specifico.
Il vero problema
Pensavi che non potessero piacermi entrambi i sistemi di avvio? Sì, e posso lavorare con entrambi.
A mio parere, il vero problema e la causa principale della maggior parte delle controversie tra SystemV e systemd è che non c'è scelta a livello di amministratore di sistema. La scelta se utilizzare SystemV o systemd è già stata fatta da sviluppatori, manutentori e packager delle varie distribuzioni, ma con buone ragioni. L'eliminazione e la sostituzione di un sistema init, per la sua natura estrema e invasiva, ha molte conseguenze che sarebbero difficili da affrontare al di fuori del processo di progettazione della distribuzione.
Nonostante questa scelta sia fatta per me, i miei host Linux si avviano e funzionano, che è ciò a cui di solito tengo di più. Come utente finale e anche come amministratore di sistema, la mia preoccupazione principale è se posso portare a termine il mio lavoro, lavori come scrivere i miei libri e questo articolo, installare aggiornamenti e scrivere script per automatizzare tutto. Finché posso fare il mio lavoro, non mi interessa davvero la sequenza di avvio utilizzata sulla mia distribuzione.
Mi interessa quando si verifica un problema durante l'avvio o la gestione del servizio. Indipendentemente dal sistema di avvio utilizzato su un host, ne so abbastanza per seguire la sequenza degli eventi per trovare l'errore e risolverlo.
Sostituzione del sistemaV
Ci sono stati precedenti tentativi di sostituire SystemV con qualcosa di un po' più moderno. Per circa due versioni, Fedora ha utilizzato una cosa chiamata Upstart per sostituire il vecchio SystemV, ma non ha sostituito init e non ha fornito modifiche che ho notato. Poiché Upstart non ha apportato modifiche significative ai problemi relativi a SystemV, gli sforzi in questa direzione sono stati rapidamente abbandonati a favore di systemd.
Nonostante il fatto che la maggior parte degli sviluppatori Linux sia d'accordo sul fatto che sostituire il vecchio avvio di SystemV sia una buona idea, molti sviluppatori e amministratori di sistema non amano systemd per questo. Piuttosto che ripassare tutti i cosiddetti problemi che le persone hanno - o hanno avuto - con systemd, ti rimando a due buoni articoli, anche se un po' vecchi, che dovrebbero coprire quasi tutto. Linus Torvalds, il creatore del kernel Linux, sembra disinteressato. In un articolo ZDNet del 2014, Linus Torvalds e altri sul sistema di Linux , Linus è chiaro sui suoi sentimenti.
"In realtà non ho opinioni particolarmente forti su systemd stesso. Ho avuto problemi con alcuni degli sviluppatori principali che penso siano troppo sprezzanti riguardo a bug e compatibilità, e penso che alcuni dettagli di progettazione siano folli (io non mi piacciono i log binari, per esempio), ma quelli sono dettagli, non grossi problemi."
Nel caso tu non sappia molto di Linus, posso dirti che se non gli piace qualcosa, è molto schietto, esplicito e abbastanza chiaro su quell'antipatia. È diventato socialmente più accettabile nel suo modo di affrontare la sua antipatia per le cose.
Nel 2013, Poettering ha scritto un lungo post sul blog in cui sfata i miti sul systemd mentre fornisce informazioni su alcuni dei motivi per crearlo. Questa è un'ottima lettura e la consiglio vivamente.
attività di sistema
A seconda delle opzioni utilizzate durante il processo di compilazione (che non sono considerate in questa serie), systemd può avere fino a 69 eseguibili binari che svolgono, tra l'altro, le seguenti attività:
- Il programma systemd viene eseguito come PID 1 e fornisce l'avvio del sistema di quanti più servizi possibile in parallelo, il che, come effetto collaterale, accelera i tempi di avvio complessivi. Gestisce anche la sequenza di spegnimento.
- Il programma systemctl fornisce un'interfaccia utente per la gestione dei servizi.
- Viene offerto il supporto per gli script di avvio SystemV e LSB per la compatibilità con le versioni precedenti.
- La gestione e il reporting del servizio forniscono più dati sullo stato del servizio rispetto a SystemV.
- Include strumenti per la configurazione di base del sistema, come nome host, data, locale, elenchi di utenti che hanno effettuato l'accesso, contenitori e macchine virtuali in esecuzione, account di sistema, directory e impostazioni di runtime, daemon per gestire una semplice configurazione di rete, sincronizzazione dell'ora di rete , inoltro dei log e risoluzione dei nomi.
- Offre la gestione dei socket.
- I timer di sistema forniscono funzionalità avanzate simili a cron per includere l'esecuzione di uno script in momenti relativi all'avvio del sistema, all'avvio di sistema, all'ultimo avvio del timer e altro ancora.
- Fornisce uno strumento per analizzare le date e gli orari utilizzati nelle specifiche del timer.
- Il montaggio e lo smontaggio di filesystem con consapevolezza gerarchica consente un collegamento a cascata più sicuro dei filesystem montati.
- Abilita la creazione e la gestione positiva di file temporanei, inclusa la cancellazione.
- Un'interfaccia per D-Bus offre la possibilità di eseguire script quando i dispositivi vengono collegati o rimossi. Ciò consente a tutti i dispositivi, collegabili o meno, di essere trattati come plug-and-play, il che semplifica notevolmente la gestione dei dispositivi.
- Il suo strumento per analizzare la sequenza di avvio può essere utilizzato per individuare i servizi che richiedono più tempo.
- Include journal per la memorizzazione dei messaggi di registro di sistema e strumenti per la gestione dei journal.
Architettura
Queste attività e altre ancora sono supportate da numerosi demoni, programmi di controllo e file di configurazione. La Figura 1 mostra molti dei componenti che appartengono a systemd. Questo è un diagramma semplificato progettato per fornire una panoramica di alto livello, quindi non include tutti i singoli programmi o file. Né fornisce alcuna visione del flusso di dati, che è così complesso che sarebbe un esercizio inutile nel contesto di questa serie di articoli.
Un'esposizione completa di systemd richiederebbe un libro da solo. Non è necessario comprendere i dettagli di come i componenti systemd nella Figura 1 si adattano; è sufficiente conoscere i programmi ei componenti che consentono di gestire vari servizi Linux e gestire file di registro e journal. Ma è chiaro che systemd non è la mostruosità monolitica che alcuni dei suoi critici sostengono che sia.
systemd come PID 1
systemd è PID 1. Alcune delle sue funzioni, che sono molto più estese del vecchio programma init SystemV3, sono la gestione di molti aspetti di un host Linux in esecuzione, incluso il montaggio di filesystem e l'avvio e la gestione dei servizi di sistema necessari per avere un host Linux produttivo. Qualsiasi attività di systemd non correlata alla sequenza di avvio non rientra nell'ambito di questo articolo (ma alcune verranno esplorate più avanti in questa serie).
Per prima cosa, systemd monta i filesystem definiti da /etc/fstab , inclusi eventuali file di scambio o partizioni. A questo punto, può accedere ai file di configurazione che si trovano in /etc , compreso il proprio. Usa il suo link di configurazione, /etc/systemd/system/default.target , per determinare in quale stato o destinazione dovrebbe avviare l'host. Il target predefinito file è un collegamento simbolico al vero file di destinazione. Per una workstation desktop, questo sarà in genere il graphical.target , che equivale al runlevel 5 in SystemV. Per un server, è più probabile che l'impostazione predefinita sia multi-user.target , che è come il runlevel 3 in SystemV. Il obiettivo.emergenza è simile alla modalità utente singolo. Gli obiettivi ei servizi sono unità di sistema.
La tabella seguente (Figura 2) confronta le destinazioni systemd con i vecchi runlevel di avvio di SystemV. systemd fornisce gli alias di destinazione systemd per la compatibilità con le versioni precedenti. Gli alias di destinazione consentono agli script e a molti amministratori di sistema di utilizzare comandi SystemV come init 3 per cambiare i runlevel. Naturalmente, i comandi SystemV vengono inoltrati a systemd per l'interpretazione e l'esecuzione.
| bersagli di sistema | Livello di esecuzione SystemV | alias di destinazione | Descrizione |
| default.target | Questo target è sempre alias con un collegamento simbolico a multi-user.target o obiettivo.grafico . systemd usa sempre default.target per avviare il sistema. Il target predefinito non dovrebbe mai essere alias di halt.target , poweroff.target o reboot.target . | ||
| obiettivo.grafico | 5 | runlevel5.target | Target.multiutente con una GUI |
| 4 | runlevel4.target | Non utilizzato. Il runlevel 4 era identico al runlevel 3 nel mondo SystemV. Questo target può essere creato e personalizzato per avviare i servizi locali senza modificare il multi-user.target predefinito . | |
| target multiutente | 3 | runlevel3.target | Tutti i servizi in esecuzione, ma solo l'interfaccia della riga di comando (CLI) |
| 2 | runlevel2.target | Multiutente, senza NFS, ma con tutti gli altri servizi non GUI in esecuzione | |
| rescue.target | 1 | runlevel1.target | Un sistema di base, incluso il montaggio dei filesystem con solo i servizi di base in esecuzione e una shell di ripristino sulla console principale |
| emergency.target | S | Modalità utente singolo:nessun servizio è in esecuzione; i filesystem non sono montati. Questo è il livello di funzionamento più elementare con solo una shell di emergenza in esecuzione sulla console principale per consentire all'utente di interagire con il sistema. | |
| halt.target | Arresta il sistema senza spegnerlo | ||
| reboot.target | 6 | runlevel6.target | Riavvia |
| poweroff.target | 0 | runlevel0.target | Arresta il sistema e spegne l'alimentazione |
Ogni destinazione ha una serie di dipendenze descritte nel suo file di configurazione. systemd avvia le dipendenze richieste, che sono i servizi richiesti per eseguire l'host Linux a un livello specifico di funzionalità. Quando tutte le dipendenze elencate nei file di configurazione di destinazione vengono caricate e in esecuzione, il sistema è in esecuzione a quel livello di destinazione. Nella Figura 2, i target con la maggior parte delle funzionalità si trovano nella parte superiore della tabella, con la funzionalità che diminuisce verso la parte inferiore della tabella.
systemd esamina anche le directory init di SystemV legacy per vedere se esistono file di avvio lì. In tal caso, systemd li utilizza come file di configurazione per avviare i servizi descritti dai file. Il servizio di rete deprecato è un buon esempio di uno che utilizza ancora i file di avvio di SystemV in Fedora.
La figura 3 (sotto) viene copiata direttamente dalla pagina man di avvio. Mostra una mappa della sequenza generale degli eventi durante l'avvio di systemd e i requisiti di ordinazione di base per garantire un avvio corretto.
cryptsetup-pre.target
|
(various low-level v
API VFS mounts: (various cryptsetup devices...)
mqueue, configfs, | |
debugfs, ...) v |
| cryptsetup.target |
| (various swap | | remote-fs-pre.target
| devices...) | | | |
| | | | | v
| v local-fs-pre.target | | | (network file systems)
| swap.target | | v v |
| | v | remote-cryptsetup.target |
| | (various low-level (various mounts and | | |
| | services: udevd, fsck services...) | | remote-fs.target
| | tmpfiles, random | | | /
| | seed, sysctl, ...) v | | /
| | | local-fs.target | | /
| | | | | | /
\____|______|_______________ ______|___________/ | /
\ / | /
v | /
sysinit.target | /
| | /
______________________/|\_____________________ | /
/ | | | \ | /
| | | | | | /
v v | v | | /
(various (various | (various | |/
timers...) paths...) | sockets...) | |
| | | | | |
v v | v | |
timers.target paths.target | sockets.target | |
| | | | v |
v \_______ | _____/ rescue.service |
\|/ | |
v v |
basic.target rescue.target |
| |
________v____________________ |
/ | \ |
| | | |
v v v |
display- (various system (various system |
manager.service services services) |
| required for | |
| graphical UIs) v v
| | multi-user.target
emergency.service | | |
| \_____________ | _____________/
v \|/
emergency.target v
graphical.target
Il sysinit.target e target.base gli obiettivi possono essere considerati punti di controllo nel processo di avvio. Sebbene uno degli obiettivi di progettazione di systemd sia l'avvio di servizi di sistema in parallelo, è necessario avviare alcuni servizi e obiettivi funzionali prima che altri servizi e obiettivi possano essere avviati. Questi checkpoint non possono essere superati finché tutti i servizi e gli obiettivi richiesti da quel checkpoint non sono stati soddisfatti.
Il sysinit.target viene raggiunto quando tutte le unità da cui dipende sono state completate. Tutte queste unità, montaggio di filesystem, configurazione di file di scambio, avvio di udev, impostazione del seme del generatore casuale, avvio di servizi di basso livello e configurazione di servizi di crittografia (se uno o più filesystem sono crittografati), devono essere completati ma, all'interno del sysinit.target , tali attività possono essere eseguite in parallelo.
Il sysinit.target avvia tutti i servizi e le unità di basso livello necessari affinché il sistema sia marginalmente funzionante e che sono necessari per consentire il passaggio a basic.target .
Dopo il sysinit.target è soddisfatto, systemd avvia quindi tutte le unità necessarie per soddisfare l'obiettivo successivo. L'obiettivo di base fornisce alcune funzionalità aggiuntive avviando le unità necessarie per tutti gli obiettivi successivi. Questi includono l'impostazione di cose come percorsi per varie directory eseguibili, socket di comunicazione e timer.
Infine, i target a livello di utente, multi-user.target o obiettivo.grafico , può essere inizializzato. Il target multiutente deve essere raggiunto prima che le dipendenze della destinazione grafica possano essere soddisfatte. Gli obiettivi sottolineati nella Figura 3 sono i soliti obiettivi di avvio. Quando uno di questi obiettivi viene raggiunto, l'avvio è completato. Se il target.multiutente è l'impostazione predefinita, quindi dovresti vedere un accesso in modalità testo sulla console. Se obiettivo.grafico è l'impostazione predefinita, quindi dovresti vedere un login grafico; la schermata di accesso alla GUI specifica che vedi dipende dal tuo display manager predefinito.
La pagina man di avvio descrive e fornisce anche le mappe dell'avvio nel disco RAM iniziale e il processo di spegnimento del sistema.
systemd fornisce anche uno strumento che elenca le dipendenze di un avvio completo o per un'unità specificata. Un'unità è un'entità di risorsa systemd controllabile che può variare da un servizio specifico, come httpd o sshd, a timer, mount, socket e altro. Prova il comando seguente e scorri i risultati.
systemctl list-dependencies graphical.targetSi noti che questo espande completamente l'elenco delle unità target di livello superiore necessarie per portare il sistema alla modalità di esecuzione target grafica. Usa --tutto opzione per espandere anche tutte le altre unità.
systemctl list-dependencies --all graphical.targetPuoi cercare stringhe come "target", "slice" e "socket" utilizzando gli strumenti di ricerca di less comando.
Quindi ora, prova quanto segue.
systemctl list-dependencies multi-user.targete
systemctl list-dependencies rescue.targete
systemctl list-dependencies local-fs.targete
systemctl list-dependencies dbus.serviceQuesto strumento mi aiuta a visualizzare le specifiche delle dipendenze di avvio per l'host su cui sto lavorando. Vai avanti e trascorri un po' di tempo esplorando l'albero di avvio per uno o più dei tuoi host Linux. Ma attenzione perché la pagina man di systemctl contiene questa nota:
"Nota che questo comando elenca solo le unità attualmente caricate in memoria dal gestore del servizio. In particolare, questo comando non è adatto per ottenere un elenco completo di tutte le dipendenze inverse su un'unità specifica, poiché non elencherà le dipendenze dichiarato dalle unità attualmente non caricate."
Pensieri finali
Anche prima di approfondire systemd, è ovvio che è potente e complesso. È anche evidente che systemd non è un file binario unico, enorme, monolitico e inconoscibile. Piuttosto, è composto da una serie di componenti e sottocomandi più piccoli progettati per eseguire attività specifiche.
Il prossimo articolo di questa serie esplorerà l'avvio di systemd in modo più dettagliato, nonché i file di configurazione di systemd, la modifica della destinazione predefinita e come creare una semplice unità di servizio.
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.
- 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.
- 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