Serie RHCSA: Gestione dei processi in RHEL 7: avvio, arresto e tutto il resto - Parte 5

Inizieremo questo articolo con una revisione generale e breve di ciò che accade dal momento in cui premi il pulsante di accensione per accendere il tuo server RHEL 7 fino a quando ti viene presentato il login schermata in un'interfaccia a riga di comando.

Si prega di notare che:

1. gli stessi principi di base si applicano, con forse piccole modifiche, anche ad altre distribuzioni Linux e
2. la seguente descrizione non intende rappresentare una spiegazione esaustiva del processo di avvio, ma solo i fondamenti.

Processo di avvio di Linux

1. Il POST (Power On Self Test) inizializza ed esegue controlli hardware.

2. Al termine del POST, il controllo del sistema viene passato al boot loader della prima fase, che è memorizzato nel settore di avvio di uno dei dischi rigidi (per i modelli più vecchi sistemi che utilizzano BIOS e MBR) o una partizione (U)EFI dedicata.

3. Il boot loader della prima fase carica quindi il boot loader della seconda fase, solitamente GRUB (GRand Unified Boot Loader), che risiede all'interno di /boot, che a sua volta carica il kernel e il file system iniziale basato sulla RAM (noto anche come initramfs, che contiene programmi e file binari che eseguono le azioni necessarie per montare il vero filesystem root).

4. Ci viene presentata una schermata iniziale che ci consente di scegliere un sistema operativo e un kernel da avviare:

5. Il kernel configura l'hardware collegato al sistema e una volta montato il filesystem root, avvia il processo con PID 1, che a sua volta inizializzerà altri processi e presenterà noi con una richiesta di accesso.

Nota: se desideriamo farlo in un secondo momento, possiamo esaminare le specifiche di questo processo utilizzando il comando dmesg e filtrando il suo output utilizzando gli strumenti che abbiamo hanno spiegato nei precedenti articoli di questa serie.

Nell'esempio sopra, abbiamo utilizzato il noto comando ps per visualizzare un elenco di processi correnti il cui processo genitore (o in altre parole, il processo che li ha avviati) è systemd (il gestore di sistema e servizi a cui sono passate la maggior parte delle moderne distribuzioni Linux) durante l'avvio del sistema:

ps -o ppid,pid,uname,comm --ppid=1

Ricorda che il flag -o (abbreviazione di –format) ti consente di presentare l'output di ps in un formato personalizzato per soddisfare le tue esigenze utilizzando le parole chiave specificate nella sezione SPECIFICATORI DEL FORMATO STANDARD in man ps.

Un altro caso in cui vorrai definire l'output di ps invece di utilizzare l'impostazione predefinita è quando hai bisogno di trovare processi che causano un carico significativo sulla CPU e/o sulla memoria e ordinarli di conseguenza:

ps aux --sort=+pcpu              # Sort by %CPU (ascending)
ps aux --sort=-pcpu              # Sort by %CPU (descending)
ps aux --sort=+pmem              # Sort by %MEM (ascending)
ps aux --sort=-pmem              # Sort by %MEM (descending)
ps aux --sort=+pcpu,-pmem        # Combine sort by %CPU (ascending) and %MEM (descending)

Un'introduzione a SystemD

Poche decisioni nel mondo Linux hanno causato più controversie dell'adozione di systemd da parte delle principali distribuzioni Linux. I sostenitori di Systemd citano come principali vantaggi i seguenti fatti:

Leggi anche: La storia dietro "init" e "systemd"

1. Systemd consente di eseguire più elaborazioni in parallelo durante l'avvio del sistema (al contrario del vecchio SysVinit, che tende sempre ad essere più lento perché avvia i processi uno per uno, controlla se uno dipende da un altro e quindi attende l'avvio dei demoni in modo che possano essere avviati più servizi) e

2. Funziona come una gestione dinamica delle risorse in un sistema in esecuzione. Pertanto, i servizi vengono avviati quando necessario (per evitare di consumare risorse di sistema se non vengono utilizzati) invece di essere avviati senza un motivo valido durante l'avvio.

3. Compatibilità con le versioni precedenti con gli script SysVinit.

Systemd è controllato dall'utilità systemctl. Se provieni da SysVinit, è probabile che tu abbia familiarità con:

1. lo strumento di servizio, che, in quei sistemi più vecchi, veniva utilizzato per gestire gli script SysVinit, e
2. l'utilità chkconfig, che aveva lo scopo di aggiornare e interrogare le informazioni sul runlevel per i servizi di sistema.
3. spegnimento, che devi aver utilizzato più volte per riavviare o arrestare un sistema in esecuzione.

La tabella seguente mostra le somiglianze tra l'uso di questi strumenti legacy e systemctl:

Systemd ha anche introdotto i concetti di unità (che può essere un servizio, un punto di montaggio, un dispositivo o un socket di rete) e di target (che è il modo in cui systemd riesce ad avviare diversi processi correlati contemporaneamente tempo e può essere considerato, sebbene non uguale, come l'equivalente dei runlevel nei sistemi basati su SysVinit.

Riassumendo

Altri compiti legati alla gestione dei processi includono, ma non sono limitati a, la capacità di:

1. Adattare la priorità di esecuzione per quanto riguarda l'utilizzo delle risorse di sistema di un processo:

Ciò viene ottenuto tramite l'utilità renice, che altera la priorità di pianificazione di uno o più processi in esecuzione. In termini semplici, la priorità di pianificazione è una funzionalità che consente al kernel (presente nelle versioni => 2.6) di allocare le risorse di sistema in base alla priorità di esecuzione assegnata (nota anche come niceness, in un intervallo da -20 fino a 19) di un dato processo.

La sintassi di base di renice è la seguente:

renice [-n] priority [-gpu] identifier

Nel comando generico riportato sopra, il primo argomento è il valore di priorità da utilizzare, mentre l'altro argomento può essere interpretato come ID di processo (che è l'impostazione predefinita), ID di gruppo di processi, ID utente o nomi utente. Un utente normale (diverso da root) può solo modificare la priorità di pianificazione di un processo di sua proprietà e solo aumentare il livello di niceness (il che significa occupare meno risorse di sistema).

2. Uccidi (o interrompi la normale esecuzione) di un processo secondo necessità:

In termini più precisi, l'uccisione di un processo dà diritto a inviargli un segnale per terminare la sua esecuzione con grazia (SIGTERM=15) o immediatamente (SIGKILL=9) tramite kill o pkill comandi.

La differenza tra questi due strumenti è che il primo viene utilizzato per terminare un processo specifico o un gruppo di processi nel suo insieme, mentre il secondo consente di fare lo stesso in base al nome e ad altri attributi.

Inoltre, pkill viene fornito in bundle con pgrep, che mostra i PID che verranno influenzati nel caso in cui venga utilizzato pkill. Ad esempio, prima di eseguire:

pkill -u gacanepa

Può essere utile visualizzare a colpo d'occhio quali sono i PID posseduti da gacanepa:

pgrep -l -u gacanepa

Per impostazione predefinita, sia kill che pkill inviano il segnale SIGTERM al processo. Come accennato in precedenza, questo segnale può essere ignorato (mentre il processo termina la sua esecuzione o per sempre), quindi quando hai seriamente bisogno di interrompere un processo in esecuzione con un motivo valido, dovrai specificare il SIGKILL segnale sulla riga di comando:

kill -9 identifier               # Kill a process or a process group
kill -s SIGNAL identifier        # Idem
pkill -s SIGNAL identifier       # Kill a process by name or other attributes 

Conclusione

In questo articolo abbiamo spiegato le basi del processo di avvio in un sistema RHEL 7 e analizzato alcuni degli strumenti disponibili per aiutarti nella gestione dei processi utilizzando utilità comuni e comandi specifici del sistema.

Tieni presente che questo elenco non è destinato a coprire tutti i fronzoli di questo argomento, quindi sentiti libero di aggiungere i tuoi strumenti e comandi preferiti a questo articolo utilizzando il modulo di commento qui sotto. Anche domande e altri commenti sono benvenuti.