Inizieremo questo articolo con una revisione generale e breve di ciò che accade dal momento in cui premi il pulsante Power per accendere il tuo server RHEL 7 fino a quando ti viene presentata la schermata di accesso in un’interfaccia a riga di comando.
Si prega di notare che:
1. gli stessi principi di base si applicano, con forse modifiche minori, 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 e esegue controlli hardware.
2. Quando il POST termina, il controllo del sistema viene passato al primo caricatore di avvio, che è memorizzato sul settore di avvio di uno dei dischi rigidi (per i sistemi più vecchi che utilizzano BIOS e MBR), o su una partizione dedicata (U)EFI.
3. Il primo caricatore di avvio carica quindi il secondo caricatore di avvio, più comunemente GRUB (GRand Unified Boot Loader), che risiede all’interno di /boot, il quale a sua volta carica il kernel e il sistema di file basato su RAM iniziale (noto anche come initramfs, che contiene programmi e file binari che eseguono le azioni necessarie per montare infine il sistema di file root effettivo).
4. Ci viene presentata una schermata di avvio 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 che il filesystem radice è stato montato, avvia il processo con PID 1, che a sua volta inizializzerà altri processi e ci presenterà un prompt di accesso.
Nota: Se desideriamo farlo in un secondo momento, possiamo esaminare i dettagli di questo processo utilizzando il comando dmesg e filtrando il suo output utilizzando gli strumenti che abbiamo spiegato nei precedenti articoli di questa serie.
Nell’esempio sopra, abbiamo utilizzato il ben noto comando ps per visualizzare un elenco dei processi attuali il cui processo padre (o in altre parole, il processo che li ha avviati) è systemd (il gestore di sistema e servizi a cui la maggior parte delle moderne distribuzioni Linux si è convertita) 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 STANDARD FORMAT SPECIFIERS in man ps.
Un altro caso in cui vorrai definire l’output di ps anziché utilizzare quello predefinito è quando devi trovare processi che stanno causando 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
Pochissime 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 a ‘init’ e ‘systemd’
1. Systemd consente di eseguire più processi in parallelo durante l’avvio del sistema (a differenza 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 poi attende che i demoni si avviino in modo che più servizi possano partire), e
2. Funziona come un gestore dinamico delle risorse in un sistema in esecuzione. Di conseguenza, i servizi vengono avviati quando necessario (per evitare di consumare risorse di sistema se non vengono utilizzati) anziché essere avviati senza una valida ragione durante l’avvio.
3. Compatibilità con gli script SysVinit.
Systemd è controllato dall’utilità systemctl. Se provieni da un background SysVinit, è probabile che tu sia familiare con:
- lo strumento service, che -in quei sistemi più vecchi- veniva utilizzato per gestire gli script SysVinit, e
- l’utilità chkconfig, che serviva allo scopo di aggiornare e interrogare le informazioni sui runlevel dei servizi di sistema.
- arresto, che devi aver usato diverse volte per riavviare o arrestare un sistema in esecuzione.
La tabella seguente mostra le somiglianze tra l’uso di questi strumenti legacy e systemctl:
| Legacy tool | Systemctl equivalent | Description |
| service name start | systemctl start name | Start name (where name is a service) |
| service name stop | systemctl stop name | Stop name |
| service name condrestart | systemctl try-restart name | Restarts name (if it’s already running) |
| service name restart | systemctl restart name | Restarts name |
| service name reload | systemctl reload name | Reloads the configuration for name |
| service name status | systemctl status name | Displays the current status of name |
| service –status-all | systemctl | Displays the status of all current services |
| chkconfig name on | systemctl enable name | Enable name to run on startup as specified in the unit file (the file to which the symlink points). The process of enabling or disabling a service to start automatically on boot consists in adding or removing symbolic links inside the /etc/systemd/system directory. |
| chkconfig name off | systemctl disable name | Disables name to run on startup as specified in the unit file (the file to which the symlink points) |
| chkconfig –list name | systemctl is-enabled name | Verify whether name (a specific service) is currently enabled |
| chkconfig –list | systemctl –type=service | Displays all services and tells whether they are enabled or disabled |
| shutdown -h now | systemctl poweroff | Power-off the machine (halt) |
| shutdown -r now | systemctl reboot | Reboot the system |
Systemd ha introdotto anche i concetti di unità (che possono essere un servizio, un punto di mount, un dispositivo o un socket di rete) e target (che è come systemd gestisce l’avvio di diversi processi correlati contemporaneamente, e può essere considerato – sebbene non uguale – come l’equivalente dei runlevel nei sistemi basati su SysVinit.
Riassumendo
Altre attività legate alla gestione dei processi includono, ma non sono limitate a, la capacità di:
1. Regolare la priorità di esecuzione per quanto riguarda l’uso delle risorse di sistema di un processo:
Ciò è realizzato tramite l’utilità renice, che modifica la priorità di scheduling di uno o più processi in esecuzione. In termini semplici, la priorità di scheduling è una funzionalità che consente al kernel (presente nelle versioni => 2.6) di allocare risorse di sistema in base alla priorità di esecuzione assegnata (chiamata niceness, in un intervallo da -20 a 19) di un dato processo.
La sintassi di base di renice è la seguente:
# renice [-n] priority [-gpu] identifier
Nel comando generico sopra, il primo argomento è il valore di priorità da utilizzare, mentre l’altro argomento può essere interpretato come processi IDs (che è l’impostazione predefinita), ID del gruppo di processi, ID utente o nomi utente. Un utente normale (oltre a root) può solo modificare la priorità di pianificazione di un processo di sua proprietà e aumentare solo il livello di piacere (il che significa utilizzare meno risorse di sistema).
2. Uccidere (o interrompere l’esecuzione normale) di un processo secondo necessità:
In termini più precisi, uccidere un processo significa inviargli un segnale per terminare la sua esecuzione in modo corretto (SIGTERM=15) o immediatamente (SIGKILL=9) tramite i comandi kill o pkill.
La differenza tra questi due strumenti è che il primo viene utilizzato per terminare un processo specifico o un gruppo di processi interamente, mentre il secondo ti consente di fare lo stesso in base al nome e ad altri attributi.
Inoltre, pkill è incluso con pgrep, che ti mostra i PID che verranno influenzati se viene utilizzato pkill. Ad esempio, prima di eseguire:
# pkill -u gacanepa
Può essere utile vedere in un colpo d’occhio quali sono i PID di proprietà di gacanepa:
# pgrep -l -u gacanepa
Per impostazione predefinita, sia kill che pkill inviano il segnale SIGTERM al processo. Come abbiamo menzionato in precedenza, questo segnale può essere ignorato (mentre il processo termina la sua esecuzione o definitivamente), quindi quando hai seriamente bisogno di fermare un processo in esecuzione con una ragione valida, dovrai specificare il segnale SIGKILL 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 i concetti di base del processo di avvio in un sistema RHEL 7, e analizzato alcuni strumenti disponibili per aiutarti a gestire i processi utilizzando utilità comuni e comandi specifici di systemd.
Nota che questa lista non intende coprire tutti gli aspetti di questo argomento, quindi sentiti libero di aggiungere i tuoi strumenti e comandi preferiti a questo articolo utilizzando il modulo di commento qui sotto. Domande e altri commenti sono anche benvenuti.
Source:
https://www.tecmint.com/rhcsa-exam-boot-process-and-process-management/