Servizi e systemd: cosa parte quando accendi Linux

Quando accendi un computer con Linux, dal tuo punto di vista succede qualcosa di molto semplice. Premi il pulsante, aspetti qualche secondo, vedi magari il logo del produttore, poi compare il menu di avvio, la schermata di login oppure direttamente l’ambiente grafico.

Sembra quasi che Linux si accenda tutto insieme.

In realtà non è così. Dietro quei pochi secondi iniziali c’è una sequenza molto precisa. Prima lavora il firmware della macchina, poi entra in gioco il bootloader, poi viene caricato il kernel, poi parte lo spazio utente e infine vengono avviati i servizi che rendono il sistema realmente utilizzabile.

In questo articolo vediamo proprio questo: cosa succede quando accendi Linux, che cosa sono i servizi Linux, che ruolo ha systemd e perché questo componente è diventato così importante nelle distribuzioni moderne.

L’obiettivo non è imparare subito tutti i comandi di amministrazione, ma costruire una mappa mentale chiara. Perché quando capisci il boot, i servizi e systemd, Linux smette di sembrare una scatola nera.

Linux non si accende tutto insieme

Una delle idee più importanti da chiarire è che Linux non parte “in blocco”. L’avvio è una catena di passaggi.

All’inizio il sistema operativo non è ancora in esecuzione. La macchina deve prima inizializzare l’hardware essenziale, capire da dove avviare il sistema e caricare i primi componenti software necessari.

Solo dopo entra in gioco il kernel Linux. E solo dopo il kernel può partire lo userspace, cioè quella parte del sistema dove vivono programmi, utility, servizi, shell, applicazioni e componenti visibili all’utente.

Questa distinzione è fondamentale, perché nei video precedenti della serie abbiamo visto che Linux è organizzato a livelli. C’è l’hardware, c’è il kernel, c’è lo spazio utente, ci sono i processi e ci sono i permessi. Il boot mette in moto tutti questi pezzi in un ordine preciso.

Quando il sistema è finalmente pronto, noi vediamo solo il risultato finale. Ma sotto sono già partiti molti componenti: gestione della rete, login, log di sistema, sessioni utente, eventuale ambiente grafico, servizi di stampa, servizi web, database o altri demoni in background.

Prima di Linux: BIOS e UEFI

Il primo componente che lavora quando accendi il computer non è Linux. È il firmware della macchina.

Storicamente si parlava di BIOS. Nei computer più moderni si parla soprattutto di UEFI. Per capire il boot Linux non è necessario entrare subito in tutte le differenze tecniche tra BIOS e UEFI. Il punto importante è il loro ruolo.

BIOS o UEFI sono il primo software eseguito dalla macchina. Il loro compito è inizializzare l’hardware essenziale, verificare che il sistema possa partire e cercare un dispositivo di avvio.

Questo dispositivo può essere un SSD interno, un disco, una chiavetta USB, una partizione specifica oppure, in alcuni casi, una risorsa di rete.

Quando il firmware trova qualcosa da cui avviare il sistema, passa il controllo al componente successivo: il bootloader.

Il bootloader e GRUB

Nel mondo Linux, il bootloader più conosciuto è GRUB.

Il bootloader è il programma che si occupa di caricare il sistema operativo. In molti computer con Linux, GRUB può mostrare un menu da cui scegliere quale sistema avviare oppure quale versione del kernel utilizzare.

Questo è particolarmente utile quando sullo stesso computer sono installati più sistemi operativi, oppure quando una distribuzione conserva più versioni del kernel per motivi di compatibilità o sicurezza.

Il compito principale di GRUB è caricare il kernel Linux in memoria e passargli eventuali parametri di avvio.

Possiamo immaginare GRUB come un ponte. Da un lato c’è il firmware della macchina, che ha trovato un dispositivo avviabile. Dall’altro lato c’è il kernel Linux, che deve essere caricato per iniziare a controllare realmente il sistema.

Quando GRUB ha fatto il suo lavoro, il protagonista diventa il kernel.

Il kernel prende il controllo

Il kernel Linux è il cuore del sistema operativo.

Durante il boot, il kernel viene caricato in memoria e inizia a preparare la macchina per l’uso. Riconosce l’hardware, prepara la gestione della CPU, della memoria, dei dispositivi, dei driver e dell’input/output.

Il kernel deve anche arrivare al filesystem principale, cioè alla radice /, la directory root da cui parte tutta la struttura del filesystem Linux.

Questa fase è essenziale, perché senza il filesystem di root il sistema non avrebbe accesso ai programmi, alle configurazioni e ai componenti necessari per continuare l’avvio.

A questo punto, però, il kernel non deve fare tutto da solo. Il suo compito è preparare le basi. Dopo aver inizializzato le parti fondamentali, deve avviare il primo processo dello spazio utente.

Qui entra in gioco il concetto di init.

Dal kernel allo userspace

Nel primo episodio della serie abbiamo distinto kernel space e user space.

Il kernel space è l’area privilegiata dove lavora il kernel. Qui vengono gestite risorse critiche come memoria, processi, filesystem, dispositivi e rete.

Lo user space, invece, è lo spazio dove girano programmi normali, shell, utility, servizi e applicazioni.

Durante il boot, dopo aver preparato l’ambiente necessario, il kernel avvia il primo processo dello user space. Questo primo processo è speciale perché da lui dipende l’avvio del resto del sistema.

Storicamente questo processo veniva chiamato init.

Nel modello classico Unix e Linux, init era il processo con PID 1. Questo numero è importante perché ogni processo Linux ha un PID, cioè un identificativo numerico. Il PID 1 è il primo processo dello spazio utente e diventa una specie di punto di partenza per molti altri processi.

Nei sistemi Linux moderni, nella maggior parte delle distribuzioni più diffuse, il ruolo di init è svolto da systemd.

Che cos’è systemd

systemd è un sistema di init moderno, ma ridurlo solo a questo sarebbe un po’ limitante.

Systemd è il componente che coordina l’avvio dello spazio utente e gestisce molti servizi del sistema. Si occupa di avviare componenti, controllare il loro stato, rispettare dipendenze, registrare errori e portare il sistema verso una condizione utilizzabile.

Quando accendi Linux, systemd può avviare il servizio di rete, il sistema di login, i componenti dell’ambiente grafico, servizi di logging, timer, mount, socket e molto altro.

Per chi inizia, systemd può sembrare un argomento molto tecnico. Ma il concetto di base è semplice: systemd coordina molti dei processi e servizi che rendono Linux operativo dopo il caricamento del kernel.

Non è il kernel. Non sostituisce il filesystem. Non è una shell. È un componente dello user space che organizza l’avvio e la gestione dei servizi.

Che cosa sono i servizi Linux

Un servizio Linux è un programma pensato per lavorare in background e fornire una funzione al sistema o agli utenti.

A differenza di un’applicazione che apri manualmente, usi e poi chiudi, un servizio spesso parte automaticamente e resta attivo per molto tempo.

Un servizio di rete permette al sistema di configurare la connessione. Un servizio di login permette agli utenti di accedere. Un servizio web risponde alle richieste HTTP. Un servizio di logging raccoglie messaggi ed eventi. Un database può restare in esecuzione come servizio per rispondere alle richieste delle applicazioni.

Questo si collega direttamente al tema dei processi. Quando un servizio è attivo, non è qualcosa di astratto: è uno o più processi Linux in esecuzione. Ha un PID, usa memoria, può consumare CPU, può aprire file, può usare la rete, può generare processi figli e può anche fallire.

La differenza è che systemd lo gestisce a un livello più alto. Non vede solo “un processo”, ma un servizio con uno stato, una configurazione, delle dipendenze e un comportamento previsto.

Unit: il concetto base di systemd

Per capire systemd bisogna conoscere il concetto di unit.

Una unit è un oggetto che systemd sa gestire. Spesso si pensa subito ai servizi, ma in realtà systemd non gestisce solo servizi.

Esistono unit di tipo diverso: service, target, socket, timer, mount e altre ancora.

Per iniziare non serve conoscerle tutte. Basta capire che una unit è una definizione che dice a systemd che cosa deve gestire e come deve farlo.

Una unit può descrivere un servizio da avviare, un obiettivo del sistema da raggiungere, un mount da preparare, un timer da eseguire periodicamente o un socket da ascoltare.

Queste unit sono normalmente descritte da file di configurazione. Per esempio, una unit di tipo servizio ha spesso un nome che termina con .service.

Service unit: i servizi gestiti da systemd

Una service unit descrive un servizio.

Quando vedi un nome come nginx.service, ssh.service o un generico web.service, stai guardando una unit che systemd può usare per gestire quel servizio.

La service unit dice a systemd come avviare il servizio, come fermarlo, da cosa dipende e come interpretare il suo stato.

Questo è un punto molto importante. Un servizio non è semplicemente “un comando lanciato a caso”. È un componente gestito del sistema.

Systemd può sapere se il servizio è attivo, se è fallito, se deve partire automaticamente al boot o se deve essere lasciato fermo finché qualcuno non lo avvia manualmente.

Questa struttura rende l’amministrazione più ordinata, perché ogni servizio può essere controllato in modo coerente.

Target unit: gli obiettivi del sistema

Un altro concetto importante è quello di target.

Un target rappresenta uno stato o un obiettivo del sistema. Possiamo immaginarlo come un gruppo di unit che, insieme, portano Linux a una determinata condizione.

Per esempio, un sistema può arrivare a uno stato testuale, adatto a un server o a una console. Oppure può arrivare a uno stato grafico, dove oltre ai servizi di base viene avviato anche il login grafico.

Il target non è un servizio nel senso classico. È più simile a una destinazione.

Systemd lavora per portare il sistema verso quel target, avviando le unit necessarie e rispettando le dipendenze tra i vari componenti.

Questa idea sostituisce in modo moderno concetti storici come i vecchi runlevel dei sistemi init tradizionali.

Le dipendenze tra servizi

Uno dei motivi per cui systemd è centrale nelle distribuzioni Linux moderne è la gestione delle dipendenze.

Non tutti i servizi possono partire in qualsiasi momento.

Un servizio web ha senso solo se il filesystem è disponibile e se la rete è pronta. Un servizio di login grafico ha senso solo dopo che il sistema ha preparato i componenti necessari. Un servizio che scrive log deve avere un sistema di logging disponibile. Un mount di rete può dipendere dalla connettività.

Systemd permette di descrivere queste relazioni.

Non si limita ad avviare tutto seguendo una lista rigida. Cerca di capire quali unit devono partire prima, quali possono partire dopo, quali sono richieste e quali invece sono opzionali.

Questo rende l’avvio più controllabile e aiuta anche a capire cosa non funziona quando un servizio fallisce.

Active, enabled, disabled e failed

Quando inizi a usare systemd, una delle cose più importanti è non confondere gli stati dei servizi.

Un servizio può essere active, cioè attivo. Questo significa che in quel momento è in esecuzione o comunque considerato correttamente avviato.

Un servizio può essere enabled, cioè abilitato all’avvio automatico. Questo non significa per forza che sia attivo in questo istante. Significa che è configurato per partire automaticamente quando il sistema raggiunge il target corretto.

Un servizio può essere disabled, cioè disabilitato. In questo caso il servizio può essere installato e può anche essere avviato manualmente, ma non partirà automaticamente al boot.

Infine, un servizio può essere failed, cioè fallito. Questo significa che systemd ha provato ad avviarlo o gestirlo, ma qualcosa è andato storto.

Questa distinzione è essenziale. Installato, attivo e abilitato non vogliono dire la stessa cosa.

Puoi avere un server web installato ma non attivo. Puoi avviarlo manualmente senza abilitarlo al boot. Oppure puoi abilitarlo in modo che parta automaticamente a ogni riavvio.

Capire questa differenza evita moltissima confusione.

Esempio: il servizio di rete

Pensiamo a un caso molto concreto: la rete.

Quando accendi un computer, ti aspetti che dopo poco la connessione sia disponibile. Se sei su un portatile, vuoi che il Wi-Fi funzioni. Se sei su un server, vuoi che la scheda di rete abbia un indirizzo IP e possa comunicare.

Ma questa cosa non avviene per magia.

Il kernel gestisce driver, dispositivi e stack di rete, ma nello user space ci sono servizi che configurano la rete secondo le regole della distribuzione.

Un servizio di rete può dipendere dal fatto che il dispositivo sia stato riconosciuto. Può avere configurazioni da leggere. Può dover aspettare altri componenti.

Systemd aiuta a coordinare tutto questo.

La rete non è un singolo interruttore. È una sequenza di componenti che devono essere pronti nel momento giusto.

Esempio: il servizio di login

Un altro esempio è il login.

Alla fine del boot, Linux deve permetterti di accedere al sistema. Questo può avvenire in modalità testuale, con una console, oppure in modalità grafica, con un display manager.

Anche in questo caso ci sono servizi coinvolti.

Un sistema server potrebbe avviare un servizio per l’accesso remoto, come SSH. Un sistema desktop potrebbe avviare un gestore grafico del login.

Quando vedi la schermata di accesso, stai già guardando il risultato di molti passaggi precedenti. Il firmware ha avviato il bootloader, il bootloader ha caricato il kernel, il kernel ha preparato il sistema e systemd ha avviato i servizi necessari.

Esempio: un servizio web

Un servizio web è un esempio perfetto per capire il ruolo di systemd.

Se su una macchina Linux installi un web server, come Apache o Nginx, questo può essere gestito come servizio.

Il servizio parte, legge la configurazione, apre una porta di rete e resta in ascolto. Quando arriva una richiesta, risponde.

Per funzionare correttamente, però, ha bisogno di molte cose. Deve trovare i file nel filesystem, deve avere permessi corretti, deve poter usare la rete, deve poter leggere la configurazione e deve poter scrivere eventuali log.

Qui si vede come tutti i concetti della serie si collegano. Il filesystem dice dove stanno file e configurazioni. I permessi decidono chi può leggere o scrivere. I processi rappresentano l’esecuzione concreta del servizio. Systemd coordina l’avvio, lo stato e la gestione del servizio.

systemctl e journalctl

Quando si lavora con systemd, due strumenti diventano molto importanti: systemctl e journalctl.

systemctl serve a osservare e controllare i servizi. Con questo comando puoi vedere lo stato di un servizio, avviarlo, fermarlo, abilitarlo o disabilitarlo.

journalctl, invece, permette di leggere il journal, cioè il sistema di log gestito da systemd.

Non è necessario imparare subito tutte le opzioni. Però è utile capire che questi strumenti sono fondamentali quando qualcosa non funziona.

Se un servizio non parte, la domanda giusta non è subito “reinstallo tutto?”. La domanda corretta è: che stato ha il servizio? Che errore mostra? Cosa dicono i log? Da quale dipendenza dipende? Ha i permessi corretti?

Questo è l’inizio del troubleshooting su Linux.

Errori comuni quando si parla di systemd

Uno degli errori più comuni è pensare che un servizio installato sia automaticamente attivo. Non è così.

Un altro errore è pensare che enabled significhi “in esecuzione ora”. Anche questo è falso. Enabled significa che il servizio è configurato per partire automaticamente, non che stia girando in questo momento.

Un altro errore molto frequente è riavviare il sistema senza leggere gli errori. A volte un servizio fallisce per una configurazione sbagliata, una porta già occupata, un file mancante o un problema di permessi. Riavviare può non risolvere nulla.

Infine, molti principianti ignorano il ruolo delle dipendenze. Alcuni servizi non partono perché manca qualcosa prima di loro. In questi casi systemd può aiutare a capire la catena del problema.

Perché systemd è così importante

Systemd è centrale perché si trova in un punto strategico del sistema.

Dopo il kernel, coordina l’avvio dello user space. Gestisce servizi, stati, dipendenze e log. Permette di abilitare o disabilitare componenti all’avvio. Aiuta a capire cosa è partito correttamente e cosa invece è fallito.

Per un utente alle prime armi può sembrare un argomento avanzato, ma in realtà è uno dei concetti più utili da capire presto.

Perché appena inizi a usare Linux in modo un po’ più consapevole, soprattutto su server, ti troverai spesso davanti a domande come: il servizio è attivo? Parte al boot? È fallito? Cosa dicono i log? Dipende dalla rete? Dipende dal filesystem? È stato avviato con l’utente giusto?

Tutte queste domande passano da systemd.

Conclusione

Linux non si accende tutto insieme. L’avvio è una sequenza ordinata.

Prima interviene BIOS o UEFI, poi il bootloader, spesso GRUB. Poi viene caricato il kernel Linux, che inizializza l’hardware, prepara memoria, driver e filesystem. Dopo il kernel parte lo spazio utente e qui entra in gioco init, che nelle distribuzioni moderne è spesso systemd.

Systemd coordina i servizi, gestisce le unit, porta il sistema verso un target, controlla dipendenze e stati.

Un servizio Linux è un processo o un insieme di processi gestiti in modo stabile dal sistema. Può essere attivo, abilitato all’avvio, disabilitato o fallito.

La cosa più importante da ricordare è questa: systemd non è un dettaglio secondario, ma uno dei componenti principali per capire cosa succede quando Linux si avvia.

Capire systemd significa capire meglio il boot, i servizi, i log, il troubleshooting e il funzionamento reale di una distribuzione Linux moderna.

Nel prossimo episodio della serie parleremo di memoria Linux, RAM, swap e memoria virtuale. Perché dopo aver capito cosa parte quando accendi il sistema, il passo successivo è capire come Linux usa le risorse mentre tutto sta funzionando.