Ricerca nel sito web

LFCS: gestione del processo e dei servizi di avvio del sistema (SysVinit, Systemd e Upstart) - Parte 7


Un paio di mesi fa, la Linux Foundation ha annunciato la certificazione LFCS (Linux Foundation Certified Sysadmin), un nuovo entusiasmante programma il cui scopo è consentire a persone provenienti da ogni parte del mondo di ottenere la certificazione nell'esecuzione di attività di amministrazione di sistema da base a intermedia su sistemi Linux. Ciò include il supporto di sistemi e servizi già in esecuzione, insieme alla ricerca e all'analisi diretta dei problemi, oltre alla capacità di decidere quando sollevare problemi ai team di ingegneri.

Il seguente video descrive una breve introduzione al programma di certificazione The Linux Foundation.

Questo post è la parte 7 di una serie di 10 tutorial. In questa parte spiegheremo come gestire il processo e i servizi di avvio del sistema Linux richiesti per l'esame di certificazione LFCS.

Gestire il processo di avvio di Linux

Il processo di avvio di un sistema Linux è composto da diverse fasi, ciascuna rappresentata da un componente diverso. Il diagramma seguente riassume brevemente il processo di avvio e mostra tutti i principali componenti coinvolti.

Quando premi il pulsante Accensione sul tuo computer, il firmware memorizzato in un chip EEPROM nella scheda madre inizializza il POST ( Autotest all'accensione) per verificare lo stato delle risorse hardware del sistema. Al termine del POST, il firmware cerca e carica il boot loader 1° stadio, situato nell'MBR o nell'EFI partizione del primo disco disponibile e gli dà il controllo.

Metodo MBR

L'MBR si trova nel primo settore del disco contrassegnato come avviabile nelle impostazioni del BIOS e ha una dimensione di 512 byte.

  1. Primi 446 byte: il bootloader contiene sia il codice eseguibile che il testo del messaggio di errore.
  2. Prossimi 64 byte: la tabella delle partizioni contiene un record per ciascuna delle quattro partizioni (primaria o estesa). Tra le altre cose, ogni record indica lo stato (attivo/non attivo), la dimensione e i settori di inizio/fine di ciascuna partizione.
  3. Ultimi 2 byte: il numero magico serve come controllo di convalida dell'MBR.

Il comando seguente esegue un backup dell'MBR (in questo esempio, /dev/sda è il primo disco rigido). Il file risultante, mbr.bkp, può tornare utile nel caso in cui la tabella delle partizioni venga danneggiata, ad esempio rendendo il sistema non avviabile.

Naturalmente, per poterlo utilizzare in seguito, in caso di necessità, dovremo salvarlo e archiviarlo altrove (ad esempio su un'unità USB). Quel file ci aiuterà a ripristinare l'MBR e ci permetterà di ripartire se e solo se nel frattempo non modifichiamo il layout del disco rigido.

Backup dell'MBR
dd if=/dev/sda of=mbr.bkp bs=512 count=1

Ripristino dell'MBR
dd if=mbr.bkp of=/dev/sda bs=512 count=1

Metodo EFI/UEFI

Per i sistemi che utilizzano il metodo EFI/UEFI, il firmware UEFI legge le proprie impostazioni per determinare quale applicazione UEFI deve essere avviata e da dove (ovvero, in quale disco e partizione viene individuata la partizione EFI).

Successivamente, viene caricato ed eseguito il boot loader della 2a fase (noto anche come boot manager). GRUB [GRand Unified Boot] è il boot manager più utilizzato in Linux. Una delle due versioni distinte può essere trovata sulla maggior parte dei sistemi utilizzati oggi.

  1. File di configurazione legacy di GRUB: /boot/grub/menu.lst (distribuzioni precedenti, non supportate dai firmware EFI/UEFI).
  2. File di configurazione GRUB2: molto probabilmente, /etc/default/grub.

Sebbene gli obiettivi dell'esame LFCS non richiedano esplicitamente la conoscenza delle parti interne di GRUB, se sei coraggioso e puoi permetterti di rovinare il tuo sistema (potresti provarlo prima su una macchina virtuale, per ogni evenienza), è necessario eseguire.

update-grub

Come root dopo aver modificato la configurazione di GRUB per applicare le modifiche.

Fondamentalmente, GRUB carica il kernel predefinito e l'immagine initrd o initramfs. In poche parole, initrd o initramfs aiutano a eseguire il rilevamento dell'hardware, il caricamento del modulo del kernel e il rilevamento del dispositivo necessari per montare il vero filesystem root.

Una volta che il vero filesystem root è attivo, il kernel esegue il gestore del sistema e dei servizi (init o systemd, il cui identificatore di processo o PID è sempre 1) per iniziare la normale procedura utente processo di avvio spaziale per presentare un'interfaccia utente.

Sia init che systemd sono demoni (processi in background) che gestiscono altri demoni, come il primo servizio ad avviarsi (durante l'avvio) e l'ultimo servizio a terminare (durante lo spegnimento).

Avvio dei servizi (SysVinit)

Il concetto di runlevel in Linux specifica diversi modi di utilizzare un sistema controllando quali servizi sono in esecuzione. In altre parole, un runlevel controlla quali attività possono essere eseguite nello stato di esecuzione corrente=runlevel (e quali no).

Tradizionalmente, questo processo di avvio veniva eseguito in base a convenzioni originate da System V UNIX, con il sistema che passava l'esecuzione di raccolte di script che avviavano e interrompevano i servizi quando la macchina entrava in uno specifico runlevel (che, in altre parole , è una modalità diversa di esecuzione del sistema).

All'interno di ogni runlevel, i singoli servizi possono essere impostati per essere eseguiti o arrestati se in esecuzione. Le ultime versioni di alcune delle principali distribuzioni si stanno allontanando dallo standard System V a favore di un servizio piuttosto nuovo e di un gestore di sistema chiamato systemd (che sta per system daemon), ma solitamente supporta i comandi sysv per motivi di compatibilità. Ciò significa che puoi eseguire la maggior parte dei noti strumenti init sysv in una distribuzione basata su systemd.

Leggi anche: Perché "systemd" sostituisce "init" in Linux

Oltre ad avviare il processo di sistema, init guarda il file /etc/inittab per decidere quale runlevel deve essere inserito.

Runlevel

Descrizione

0

Arrestare il sistema. Il runlevel 0 è uno stato transitorio speciale utilizzato per arrestare rapidamente il sistema.

1

Chiamato anche s o S, questo runlevel è talvolta chiamato modalità di manutenzione. Gli eventuali servizi avviati a questo runlevel variano in base alla distribuzione. Viene in genere utilizzato per la manutenzione del sistema di basso livello che potrebbe essere compromessa dal normale funzionamento del sistema.

2

Multiutente. Sui sistemi Debian e derivati, questo è il runlevel predefinito e include, se disponibile, un accesso grafico. Sui sistemi basati su Red-Hat, questa è la modalità multiutente senza rete.

3

Sui sistemi basati su RedHat, questa è la modalità multiutente predefinita, che esegue tutto tranne l'ambiente grafico. Questo runlevel e i livelli 4 e 5 solitamente non vengono utilizzati sui sistemi basati su Debian.

4

Tipicamente inutilizzato per impostazione predefinita e quindi disponibile per la personalizzazione.

5

Sui sistemi basati su RedHat, modalità multiutente completa con accesso alla GUI. Questo runlevel è come il livello 3, ma con un accesso alla GUI disponibile.

6

Riavviare il sistema.

Per passare da un runlevel all'altro, possiamo semplicemente emettere una modifica del runlevel utilizzando il comando init: init N (dove N è uno dei runlevel elencati sopra). Tieni presente che questo non è il modo consigliato per portare un sistema in esecuzione a un runlevel diverso perché non fornisce alcun avviso agli utenti esistenti che hanno effettuato l'accesso (causando così loro la perdita di lavoro e la terminazione anomala dei processi).

Invece, il comando shutdown dovrebbe essere utilizzato per riavviare il sistema (che prima invia un messaggio di avviso a tutti gli utenti registrati e blocca qualsiasi ulteriore accesso; quindi segnala a init di cambiare runlevel); tuttavia, il runlevel predefinito (quello dal quale verrà avviato il sistema) deve essere prima modificato nel file /etc/inittab.

Per questo motivo, segui questi passaggi per passare correttamente da un runlevel all'altro. Come root, cerca la seguente riga in /etc/inittab.

id:2:initdefault:

e modifica il numero 2 per il runlevel desiderato con il tuo editor di testo preferito, come vim (descritto in Come utilizzare l'editor vi/vim in Linux – Parte 2 di questa serie).

Successivamente, esegui come root.

shutdown -r now

Quel comando ultimo riavvierà il sistema, facendolo avviare nel runlevel specificato all'avvio successivo, ed eseguirà gli script che si trovano in /etc/rc[runlevel].d directory per decidere quali servizi dovrebbero essere avviati e quali no. Ad esempio, per il runlevel 2 nel seguente sistema.

Gestisci i servizi utilizzando chkconfig

Per abilitare o disabilitare i servizi di sistema all'avvio, utilizzeremo il comando chkconfig in CentOS/openSUSE e sysv-rc-conf in Debian e derivati. Questo strumento può anche mostrarci qual è lo stato preconfigurato di un servizio per un particolare runlevel.

Leggi anche: Come arrestare e disattivare i servizi indesiderati in Linux

Elenca la configurazione del runlevel per un servizio.

chkconfig --list [service name]
chkconfig --list postfix
chkconfig --list mysqld

Nell'immagine sopra possiamo vedere che postfix è impostato per avviarsi quando il sistema accede ai runlevel da 2 a 5, mentre mysqld verrà eseguito per impostazione predefinita per i runlevel da 2 a 4. Supponiamo ora che questo non sia il comportamento atteso.

Ad esempio, dobbiamo attivare mysqld anche per il runlevel 5 e disattivare postfix per i runlevel 4 e 5. Ecco cosa faremo in ciascun caso (eseguire il comando seguendo i comandi come root).

Abilitazione di un servizio per un particolare runlevel
chkconfig --level [level(s)] service on
chkconfig --level 5 mysqld on
Disabilitare un servizio per runlevel particolari
chkconfig --level [level(s)] service off
chkconfig --level 45 postfix off

Ora eseguiremo attività simili in un sistema basato su Debian utilizzando sysv-rc-conf.

Gestisci i servizi utilizzando sysv-rc-conf

Configurazione di un servizio per l'avvio automatico su un runlevel specifico e per impedirne l'avvio su tutti gli altri.

1. Usiamo il comando seguente per vedere quali sono i runlevel in cui mdadm è configurato per l'avvio.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

2. Utilizzeremo sysv-rc-conf per impedire l'avvio di mdadm su tutti i runlevel tranne 2. Basta selezionare o deselezionare (con la barra spaziatrice) come desiderato (puoi spostarti su, giù, sinistra e destra con i tasti freccia).

sysv-rc-conf

Quindi premi q per uscire.

3. Riavvieremo il sistema ed eseguiremo nuovamente il comando dal PASSO 1.

ls -l /etc/rc[0-6].d | grep -E 'rc[0-6]|mdadm'

Nell'immagine sopra possiamo vedere che mdadm è configurato per avviarsi solo sul runlevel 2.

Che dire di systemd?

systemd è un altro servizio e gestore di sistema adottato da diverse importanti distribuzioni Linux. Ha lo scopo di consentire più elaborazioni in parallelo durante l'avvio del sistema (a differenza di sysvinit, che tende sempre ad essere più lento perché avvia i processi uno alla volta, controlla se uno dipende da un altro e attende demoni da avviare in modo che possano essere avviati più servizi) e per fungere da gestione dinamica delle risorse per un sistema in esecuzione.

Pertanto, i servizi vengono avviati quando necessario (per evitare di consumare risorse di sistema) invece di essere avviati senza una valida ragione durante l'avvio.

Visualizzando lo stato di tutti i processi in esecuzione sul tuo sistema, sia i servizi systemd nativi che SysV, esegui il seguente comando.

systemctl

La colonna LOAD mostra se la definizione dell'unità (fare riferimento alla colonna UNIT, che mostra il servizio o qualsiasi cosa gestita da systemd) è stata caricata correttamente, mentre la colonna ACTIVE< Le colonne e SUB mostrano lo stato corrente di tale unità.

Visualizzazione delle informazioni sullo stato corrente di un servizio

Quando la colonna ACTIVE indica che lo stato di un'unità è diverso da attivo, possiamo verificare cosa è successo utilizzando.

systemctl status [unit]

Ad esempio, nell'immagine sopra, media-samba.mount è in stato non riuscito. Corriamo.

systemctl status media-samba.mount

Possiamo vedere che media-samba.mount non è riuscito perché il processo di montaggio sull'host dev1 non è riuscito a trovare la condivisione di rete su //192.168.0.10/gacanepa.

Avvio o interruzione dei servizi

Una volta che la condivisione di rete //192.168.0.10/gacanepa diventa disponibile, proviamo ad avviare, quindi arrestare e infine riavviare l'unità media-samba.mount. Dopo aver eseguito ciascuna azione, eseguiamo systemctl status media-samba.mount per verificarne lo stato.

systemctl start media-samba.mount
systemctl status media-samba.mount
systemctl stop media-samba.mount
systemctl restart media-samba.mount
systemctl status media-samba.mount

Abilitare o disabilitare l'avvio di un servizio durante l'avvio

Sotto systemd puoi abilitare o disabilitare un servizio all'avvio.

systemctl enable [service] 		# enable a service 
systemctl disable [service] 		# prevent a service from starting at boot

Il processo di abilitazione o disabilitazione dell'avvio automatico di un servizio all'avvio consiste nell'aggiungere o rimuovere collegamenti simbolici nella directory /etc/systemd/system/multi-user.target.wants.

In alternativa, puoi scoprire lo stato attuale di un servizio (abilitato o disabilitato) con il comando.

systemctl is-enabled [service]

Per esempio,

systemctl is-enabled postfix.service

Inoltre, puoi riavviare o spegnere il sistema con.

systemctl reboot
systemctl shutdown

Iniziare

Upstart è un sostituto basato su eventi del demone /sbin/init ed è nato dall'esigenza di avviare i servizi solo quando sono necessari (supervisionandoli anche mentre sono in funzione) sono in esecuzione) e gestendo gli eventi man mano che si verificano, superando così il classico sistema sysvinit basato sulle dipendenze.

È stato originariamente sviluppato per la distribuzione Ubuntu, ma viene utilizzato in Red Hat Enterprise Linux 6.0. Anche se doveva essere adatto all'implementazione in tutte le distribuzioni Linux come sostituto di sysvinit, col tempo fu messo in ombra da systemd. Il 14 febbraio 2014, Mark Shuttleworth (fondatore di Canonical Ltd.) ha annunciato che le versioni future di Ubuntu utilizzeranno systemd come demone init predefinito.

Poiché lo script di avvio SysV per il sistema è stato così comune per così tanto tempo, un gran numero di pacchetti software include script di avvio SysV. Per accogliere tali pacchetti, Upstart fornisce una modalità di compatibilità: esegue gli script di avvio SysV nelle solite posizioni (/etc/rc.d/rc?.d, /etc/init.d/ rc?.d, /etc/rc?.d o una posizione simile). Pertanto, se installiamo un pacchetto che non include ancora uno script di configurazione Upstart, dovrebbe comunque avviarsi nel solito modo.

Inoltre, se abbiamo installato utilità come chkconfig, dovresti essere in grado di usarle per gestire i tuoi servizi basati su SysV proprio come faremmo con i sistemi basati su sysvinit.

Gli script Upstart supportano anche l'avvio o l'arresto dei servizi in base a una più ampia varietà di azioni rispetto agli script di avvio SysV; ad esempio, Upstart può avviare un servizio ogni volta che viene collegato un particolare dispositivo hardware.

Un sistema che utilizza Upstart e i suoi script nativi sostituisce esclusivamente il file /etc/inittab e le directory degli script di avvio SysV specifiche del runlevel con .conf script nella directory /etc/init.

Questi script *.conf (noti anche come definizioni di lavoro) sono generalmente costituiti da quanto segue:

    1. Descrizione del processo.
    2. Runlevel in cui dovrebbe essere eseguito il processo o eventi che dovrebbero attivarlo.
    3. Runlevel in cui il processo dovrebbe essere interrotto o eventi che dovrebbero interromperlo.
    4. Opzioni.
    5. Comando per avviare il processo.

Per esempio,

My test service - Upstart script demo description "Here goes the description of 'My test service'" author "Dave Null <[email >"
Stanzas

#
Stanzas define when and how a process is started and stopped
See a list of stanzas here: http://upstart.ubuntu.com/wiki/Stanzas#respawn
When to start the service
start on runlevel [2345]
When to stop the service
stop on runlevel [016]
Automatically restart process in case of crash
respawn
Specify working directory
chdir /home/dave/myfiles
Specify the process/command (add arguments if needed) to run
exec bash backup.sh arg1 arg2

Per applicare le modifiche, dovrai dire a upstart di ricaricare la sua configurazione.

initctl reload-configuration

Quindi avvia il tuo lavoro digitando il seguente comando.

sudo start yourjobname

Dove yourjobname è il nome del lavoro che è stato aggiunto in precedenza con lo script yourjobname.conf.

Una guida di riferimento più completa e dettagliata per Upstart è disponibile nel sito web del progetto nel menu “Cookbook”.

Riepilogo

È necessaria una conoscenza del processo di avvio di Linux per aiutarti nelle attività di risoluzione dei problemi, nonché per adattare le prestazioni del computer e eseguire i servizi alle tue esigenze.

In questo articolo abbiamo analizzato cosa succede dal momento in cui si preme l'interruttore di Power per accendere la macchina fino ad ottenere un'interfaccia utente completamente operativa. Spero che tu abbia imparato leggendolo tanto quanto ho imparato io mentre lo mettevo insieme. Sentiti libero di lasciare i tuoi commenti o domande qui sotto. Aspettiamo sempre il parere dei nostri lettori!