Tutorial completo del comando systemctl in Linux

Dominare systemctl e systemd Al giorno d'oggi è praticamente obbligatorio per chi gestisce server o sistemi Linux moderni. Questo strumento è la porta d'accesso per controllare quali servizi si avviano, come si avviano, cosa è andato storto e lo stato effettivo del sistema in un dato momento. Una volta presa la mano, vi risparmierete un sacco di mal di testa e molti riavvii inutili.

In questa guida vedrai in modo ordinato e con esempi come utilizzare systemctl per gestire servizi, unità e obiettiviCome elencare cosa sta succedendo nel sistema, come modificare le unità senza rompere nulla, cosa significano gli stati come abilitato, mascherato o staticoE inoltre Tricks Per spegnere, riavviare o passare dalla modalità grafica a quella di testo con un singolo comando. Il tutto utilizzando un Spagnolo dalla Spagna, diretto e pratico, progettato in modo da poter applicare quanto letto a qualsiasi distribuzione basata su systemd (Ubuntu, Debian, RHEL, CentOS, Fedora, Arch, ecc.).

Che cos'è systemd e quale ruolo svolge systemctl?

Nella maggior parte delle distribuzioni attuali, systemd funge da sistema di avvio e infrastruttura di baseÈ il processo che inizia subito dopo il kernel (solitamente come PID 1) ed è responsabile dell'avvio del resto dei servizi, del montaggio dei file system, della gestione delle dipendenze, del controllo delle sessioni, della registrazione degli eventi e molto altro ancora.

systemd è composto da demoni, librerie e utilità che consentono la comunicazione con il kernel e lo spazio utente: gestisce gruppi di controllo (cgroup), socket, timer, punti di montaggio, configurazione di rete di base, sincronizzazione dell'ora, risoluzione dei nomi, contenitori e Macchine virtualied è persino compatibile con i vecchi script SysV e LSB, quindi può sostituire completamente Sysvinit classico.

All'interno di questo intero ecosistema, systemctl è il "telecomando" di systemdÈ l'utilità online di comandi che usi per:

• Avvia, arresta, riavvia o ricarica i servizi e altri tipi di unità.
• Abilita o disabilita le unità in modo che possano iniziare (o meno) con il sistema.
• Controlla lo stato dei servizi, degli obiettivi e del sistema in generale.
• Modifica i file dell'unità oppure visualizzarne le dipendenze e le proprietà interne.
• Cambia lo stato globale del sistema (modalità di salvataggio, multiutente, grafica, spegnimento, riavvio…).

Si noti che non tutte le distribuzioni utilizzano systemd. Se durante l'esecuzione systemctl Viene visualizzato un messaggio come questo: bash: systemctl: command not found Oppure qualcosa di simile; il tuo sistema probabilmente utilizza un sistema init diverso (OpenRC, runit, SysV puro, ecc.). In tal caso, I comandi in questa guida non si applicano tal quale.

Unità e file di unità in systemd

Il concetto chiave in systemd è il unitàUn'unità rappresenta qualsiasi risorsa che systemd è in grado di gestire: un servizio, un socket, un punto di montaggio, un dispositivo, un obiettivo globale di sistema, un timer... Ogni tipo di unità è identificato da un suffisso nel nome del file.

Alcuni dei tipi più comuni di unità che vedrai quando lavori con systemctl e systemd sono:

• .service: servizi e demoni (nginx.service, SSH.service, NetworkManager.service…).
• .PRESA: socket associati ai servizi avviati su richiesta.
• .montare: punti di montaggio del file system.
• .automount: assemblaggi automatici attivati ​​per l'uso.
• .bersaglio: “stati” del sistema (multi-user.target, graphical.target, rescue.target…).
• .Timer: timer che avviano i servizi in momenti specifici.
• .dispositivo: dispositivi gestiti da udev.
• .sentiero: monitora i percorsi sul disco che attivano i servizi.

Ogni unità è definita in un file di unitàche è un file di testo con sezioni come , , , dove la descrizione, le dipendenze e i comandi sono dettagliati Boot, utente che esegue il servizio, ecc. Questi file sono in genere archiviati in:

• /lib/systemd/sistema/ o /usr/lib/systemd/sistema/: unità fornite con i pacchetti.
• /etc/systemd/system/: unità definite o sovrascritte dall'amministratore.

quando lavori con systemctlSi fa quasi sempre riferimento ad unità di tipo .serviceTuttavia, se si omette il suffisso, systemd presume per impostazione predefinita che si stia facendo riferimento a un servizio. Ovvero, systemctl start ssh y systemctl start ssh.service sono equivalenti.

Ci sono unità speciali chiamate modelli, il cui nome include @, per esempio name@.serviceQuando si crea un'istanza di un modello come name@miinstancia.serviceQuello che stai facendo è creare un un'istanza specifica che passa un identificatore; all'interno del file unitario, la variabile %i Viene sostituito da quell'identificatore. Questo è comunemente usato nei tunnel SSH, nei servizi di interfaccia di rete, ecc.

Controlla se il tuo sistema utilizza systemd

Prima di impazzire con i comandi, è una buona idea controllare se la tua distribuzione sta effettivamente utilizzando systemd come PID 1Molte guide suggeriscono qualcosa di semplice come:

pstree | head -5

Se in cima all'albero vedi un processo systemdPuoi procedere senza problemi. Se vedi un sistema di avvio diverso, dovrai utilizzare gli strumenti specifici per quel sistema di avvio.

Gestione dei servizi di base con systemctl

Le operazioni quotidiane con systemd si concentrano in genere su Avvia, arresta, riavvia e ricarica i serviziQuesti comandi influenzano lo stato attuale del servizio, non se verrà avviato automaticamente o meno con il sistema.

a controllare lo stato di un servizio, Puoi usare:

systemctl status nombre_servicio.service

Ad esempio, per vedere come funziona il servizio di rete systemd-networkd su un sistema Ubuntu in modalità testo:

systemctl status systemd-networkd.service

Questo comando visualizza informazioni abbastanza dettagliate: stato (attivo, inattivo, fallito…), quando è stato attivato, il PID principale, l'utilizzo della CPU e alcuni messaggi di registro recenti che sono molto utili per diagnosticare i problemi.

Se preferisci qualcosa di più diretto, puoi usare queste varianti specifiche:

• systemctl is-active name.service: indica se è attivo (in esecuzione) oppure no.
• systemctl is-enabled name.service: indica se inizierà dall'inizio.
• systemctl is-failed name.service: controlla se è entrato in uno stato di errore.

Ad esempio, per verificare se systemd-networkd è abilitato all'avvio, puoi eseguire:

systemctl is-enabled systemd-networkd.service

E per scoprire se in qualche momento non è riuscito ad avviarsi:

systemctl is-failed systemd-networkd.service

Avvio, arresto, riavvio e ricaricamento dei servizi

a interrompere un servizio in esecuzioneL'ordine tipico è:

sudo systemctl stop nombre_servicio.service

Tieni presente che poiché questa è un'azione che influisce sul sistema, avrai bisogno privilegi di amministrazione, normalmente utilizzando sudoIn alcuni servizi "ostinati", come systemd-networkd, l'arresto ne causerà il riavvio immediato se è presente un'unità che li richiede e dispone di criteri di riavvio automatico.

Se il servizio è interrotto e vuoi avviarloSi usa lo stesso schema con start:

sudo systemctl start systemd-networkd.service

Quando hai modificato un file di configurazione e vuoi applicare le modifiche, la cosa più comune da fare è riavviare il servizio:

sudo systemctl restart nombre_servicio.service

Molti demoni permettono Ricarica le impostazioni senza riavviare completamenteevitando di interrompere le connessioni attive. In questi casi, si utilizza quanto segue:

sudo systemctl reload nombre_servicio.service

Se non sei sicuro che il servizio supporti le ricariche, puoi provare:

sudo systemctl reload-or-restart nombre_servicio.service

Con questo comando, systemctl tenta prima di ricaricare E se l'unità non esegue un ricaricamento, procede a un riavvio completo. Questo è molto utile quando non si ricorda il comportamento specifico di ciascun demone.

Abilita e disabilita i servizi all'avvio

Tutto ciò che abbiamo visto finora riguarda solo il sessione correnteSe si desidera che un servizio venga avviato automaticamente all'avvio del sistema, è necessario abilitarloIl comando di base è:

sudo systemctl enable nombre_servicio.service

In questo modo, systemd crea collegamenti simbolici dal file del servizio di sistema (solitamente in /lib/systemd/system o /etc/systemd/system) fino a una directory .wants corrispondente al bersaglio su cui deve essere attivato. Ad esempio, qualcosa del tipo:

/etc/systemd/system/multi-user.target.wants/nombre_servicio.service

Se vuoi esattamente l'opposto, cioè, impedire l'avvio automatico di un servizio Disattivalo al prossimo avvio:

sudo systemctl disable nombre_servicio.service

Ciò rimuove i collegamenti di avvio simbolici, ma Non interrompe il servizio già in esecuzioneAllo stesso modo, l'abilitazione di un servizio non lo avvia immediatamente: sarà effettivo solo dopo il successivo riavvio, a meno che non si combini quanto segue:

sudo systemctl enable nombre_servicio.service
sudo systemctl start nombre_servicio.service

Alcune distribuzioni e strumenti offrono scorciatoie per abilitare e avviare contemporaneamenteTuttavia, il metodo standard con systemctl è solitamente quello di eseguire entrambi i comandi.

Visualizza lo stato generale delle unità

systemctl non è utile solo per toccare singoli servizi; consente anche per avere una panoramica del sistemaIl comando più tipico è:

systemctl list-units

Questo elenco mostra tutte le unità attive presenti in memoria in systemd. Le colonne principali sono:

• UNITA ': nome dell'unità (ad esempio, sshd.service).
• CARICARE: se il file dell'unità è stato caricato correttamente (caricato, non trovato, errore...).
• ATTIVO: stato generale (attivo, inattivo, fallito…).
• SUB: sottostato più descrittivo (in esecuzione, uscito, morto, fallito…).
• DESCRIZIONE: breve descrizione dell'unità.

Se chiami systemctl senza argomentiVedrai praticamente lo stesso elenco, poiché questo è il comportamento predefinito. Poiché vengono visualizzate solo le unità attive, quasi tutto apparirà con LOAD=caricato e ACTIVE=attivo.

Per includere anche le unità inattive, puoi aggiungere l'indicatore --all:

systemctl list-units --all

Puoi anche filtrare per stato con --state=Ad esempio, per visualizzare solo le unità inattive:

systemctl list-units --all --state=inactive

Oppure filtra per tipo di unità con --type=Ad esempio, per visualizzare solo i servizi attivi:

systemctl list-units --type=service

Elenca tutti i file dell'unità installati

L'elenco sopra mostra solo le unità che systemd ha tentato di caricare. Per saperne di più. tutte le unità presenti sul discoChe li utilizziate o meno, dovete ricorrere a:

systemctl list-unit-files

Qui l'attenzione è rivolta ai file unitari stessi, non al loro stato in memoria. Vedrai due colonne principali: FILE UNITÀ y STATOIn STATE compaiono valori come i seguenti:

• abilitatoL'unità è configurata per l'avvio automatico.
• disabile: Non è configurato per l'avvio automatico.
• staticoL'unità non ha sezione Quindi non può abilitarsiDi solito si tratta di una dipendenza da altre unità o dell'esecuzione di un'azione specifica.
• mascheratoL'unità è completamente bloccata e non può essere avviata in alcun modo.

Puoi anche filtrare in base allo stato, ad esempio per vedere solo le unità abilitate:

systemctl list-unit-files --state=enabled

Oppure combina più stati in un'unica query separandoli con virgole:

systemctl list-unit-files --state=enabled,failed

Visualizza dettagli, proprietà e dipendenze di un'unità

Se desideri visualizzare il contenuto effettivo del file dell'unità Poiché systemd utilizza il comando più comodo, è:

systemctl cat nombre.service

Questo mostra il file come lo vede systemd, inclusi eventuali frammenti di override da /etc/systemd/systemÈ molto utile per confermare che le modifiche siano state effettivamente prese in considerazione.

Per ispezionare il albero delle dipendenze Da un'unità è possibile utilizzare:

systemctl list-dependencies nombre.service

L'output è gerarchico e mostra quali obiettivi e servizi guidano il servizio in questione. Le unità di tipo .bersaglio Agiscono come punti di raggruppamento e solo loro mostrano ricorsivamente le loro dipendenze per impostazione predefinita; se si desidera espandere l'intero albero, aggiungere --all.

Se quello che ti serve sapere è quali unità dipendono da quella che hai indicato, Aggiungere --reverse al comando. E se vuoi concentrarti sull'ordine di avvio, i flag --before y --after Mostrano le unità che devono iniziare prima o dopo l'unità bersaglio.

Per vedere tutto proprietà interne di un'unità nel formato chiave=valore, utilizzare:

systemctl show nombre.service

E se sei interessato solo a una proprietà specifica, puoi filtrare con -pAd esempio, per visualizzare i conflitti sshd:

systemctl show sshd.service -p Conflicts

Unità di mascheramento e smascheramento

Oltre a disabilitare, systemd consente mascherare un'unità in modo che sia completamente impossibile avviarlaQuesta tecnica viene utilizzata quando si vuole essere sicuri al 100% che qualcosa non si avvii, nemmeno accidentalmente. Questa operazione può essere eseguita manualmente o affidandosi a un'altra unità.

Il mascheramento viene implementato creando un collegamento simbolico a /dev/null invece del file di unità effettivo. Per mascherare un servizio, ad esempio nginx:

sudo systemctl mask nginx.service

Se poi corri systemctl list-unit-files, lo vedrai nginx.service appare come mascheratoE se provi ad avviarlo:

sudo systemctl start nginx.service

Riceverai un messaggio come questo: Impossibile avviare nginx.service: l'unità nginx.service è mascherata. In altre parole, l'unità è corazzata. Per renderla nuovamente utilizzabile, è necessario smascherarla:

sudo systemctl unmask nginx.service

Dopodiché l'unità torna allo stato precedente (abilitata, disabilitata, statica, ecc.) e può essere avviata o abilitata normalmente.

Modifica i file dell'unità senza danneggiare il sistema

A volte è necessario modificare il comportamento di un servizio: cambiare l'utente che lo esegue, aggiungere opzioni della riga di comando, modificare le dipendenze... Invece di modificare manualmente i file in /lib/systemd/systemLa cosa più sicura è usare il proprio systemctl per generare override.

Il comando base è:

sudo systemctl edit nombre.service

Questo apre l'editor predefinito con un file frammento vuotoQuando salvi ed esci, systemd creerà una directory in /etc/systemd/system/nombre.service.d/ e all'interno di un file override.confQuando si carica l'unità, systemd unisce il file originale con questo frammento e le direttive di override hanno la priorità su quelli del file base.

Se vuoi modificare il file completo dell'unità Invece di un override, puoi farlo con:

sudo systemctl edit --full nombre.service

In questo caso, ciò che salvi verrà scritto su /etc/systemd/system/nombre.serviceche ha la precedenza sulla versione del sistema in /lib/systemd/systemÈ un modo per "clonare" e personalizzare completamente un'unità senza toccare i file inclusi nel pacchetto.

Se in seguito decidi di annullare le modifiche, è sufficiente eliminare la directory .d dell'override o del file di servizio modificato in /etc/systemd/system. Ad esempio:

sudo rm -r /etc/systemd/system/nginx.service.d
sudo rm /etc/systemd/system/nginx.service

Dopo aver eliminato questi elementi, è molto importante eseguire:

sudo systemctl daemon-reload

Ciò forza systemd a Ricarica tutti i file dell'unitàDimenticatevi delle sostituzioni rimosse e tornate a utilizzare le definizioni di sistema originali.

Obiettivi e adattamento del runlevel

I gli obiettivi systemd sono l'equivalente moderno dei runlevel da SysV. Sono unità speciali (terminano in .target) che raggruppano altre unità per rappresentare “stati” o punti di sincronizzazione del sistema.

Ad esempio:

• multiutente.target: modalità console multiutente, tipica dei server senza ambiente grafico.
• grafico.target: modalità grafica; di solito dipende da multi-user.target e aggiunge il livello di interfaccia grafica.
• salvataggio.target: modalità di salvataggio, simile alla "modalità utente singolo".
• swap.target: punto in cui l'area di scambio è pronta per l'uso.

Le unità possono dichiarare relazioni come WantedBy=, RequiredBy=, Wants=, Requires=, After= con questi obiettivi per indicare da cosa dipendono e in quale ordine devono essere raggiunti.

Per scoprire Qual è l'obiettivo prefissato? del tuo sistema (lo stato che vuoi raggiungere in un avvio normale), usa:

systemctl get-default

Ad esempio, se preferisci che il sistema si avvii sempre in modalità grafica, puoi modificarlo con:

sudo systemctl set-default graphical.target

Per visualizzare tutti i target installati sul sistema, con il loro stato (abilitato, disabilitato...), puoi eseguire:

systemctl list-unit-files --type=target

E se quello che vuoi è vedere quali obiettivi sono attivi in ​​questo momentoLo fai con:

systemctl list-units --type=target

Isolare gli obiettivi e cambiare la modalità di lavoro

Una delle cose più potenti che systemd offre è la capacità di modificare lo stato del sistema “isolando” un targetQuando si esegue un isolamento, systemd attiva tutte le unità necessarie per tale obiettivo e arresta quelle che non rientrano più nel suo albero delle dipendenze.

Immagina di essere in un ambiente grafico (attivo grafico.targete si desidera passare a un ambiente multiutente solo testo, ad esempio per attività di manutenzione. È possibile innanzitutto verificare le dipendenze di multi-user.target:

systemctl list-dependencies multi-user.target

E quando sei sicuro di non danneggiare nulla di critico, esegui:

sudo systemctl isolate multi-user.target

Poiché graphical.target dipende da multi-user.target ma non viceversa, isolando il target multi-utente lo si interromperà. tutti i servizi associati al livello graficolasciandoti in modalità testo. È un cambiamento piuttosto radicale, quindi usalo con saggezza.

Per eventi molto comuni, systemctl offre scorciatoie convenienti rispetto alla scrittura isolata a mano. Alcuni dei più comunemente usati sono:

• sudo systemctl rescue: passa alla modalità di salvataggio (equivalente all'isolamento di rescue.target) e avvisa gli utenti connessi.
• sudo systemctl halt: arresta il sistema (simile allo spegnimento della CPU senza interrompere l'alimentazione).
• sudo systemctl poweroffSpegnere completamente la macchina.
• sudo systemctl riavvio: riavvia il sistema.

In genere, i comandi classici come reboot, poweroff o halt Sono collegati internamente per comunicare con systemd, quindi si comportano in modo coerente con queste scorciatoie.

Ulteriori comandi essenziali di systemctl

Oltre a tutto quanto sopra, ci sono alcuni comandi per systemctl che dovresti tenere a portata di mano perché li userai spesso quando lavori con le unità:

Ricarica la configurazione di systemd (non i servizi):

sudo systemctl daemon-reload

Ogni volta che modifichi o aggiungi file di unità, devi avvisare systemd in modo che possa rileggerli. Questo comando i servizi non si riavvianoRicarica solo il database dell'unità.

Controlla lo stato di un servizio con i dettagli (già discusso):

sudo systemctl status nombre_servicio.service

Qui vedrai lo stato Caricato, Attivo, PID, tempo di attività e gli ultimi messaggi di registro, preziosi per il debug degli errori.

Abilita e disabilita i servizi (visto anche):

sudo systemctl enable nombre_servicio.service
sudo systemctl disable nombre_servicio.service

Avvia, arresta e riavvia i servizi esplicitamente:

sudo systemctl start nombre_servicio.service
sudo systemctl stop nombre_servicio.service
sudo systemctl restart nombre_servicio.service

Questi modelli si ripetono praticamente con qualsiasi servizio, da apache2, nginx o ssh, fino ai servizi di database, demoni dell'impressione o qualsiasi altra cosa ti venga in mente.

Gestione del servizio: avvio, ricarica, arresto e monitoraggio

In un contesto reale, utilizzerai systemctl per mantenere i servizi essenziali sempre attivi e funzionanti: server web, database, servizi di rete, demoni di riservaecc. L'idea è di minimizzare il tempo di inattività e applicare modifiche alla configurazione con il minimo impatto possibile.

a avviare un servizio che dovrebbe essere attivo (ad esempio, Apache), il comando tipico sarebbe:

sudo systemctl start apache2

Se Apache era già in esecuzione, non noterai nulla di insolito; se è stato arrestato, il demone avvierà i processi figlio e inizierà a gestire le richieste. Ogni volta che non sei sicuro di cosa sia successo, esegui i seguenti comandi:

sudo systemctl status apache2

Quando si modifica il file di configurazione principale o alcuni host virtuale, di solito ricaricare o Reiniciar Il servizio. La ricarica è più fluida:

sudo systemctl reload apache2

Ciò consente al servizio di rileggere i file di configurazione senza interrompere i processi in esecuzione, in modo che gli utenti non si accorgano praticamente di nulla. Se, per qualsiasi motivo, il servizio non supporta il ricaricamento, è necessario:

sudo systemctl restart apache2

In alcuni casi, se il servizio presenta problemi o non risponde più, potrebbe essere necessario un riavvio completo. libera risorse e pulisce i processi zombieÈ uno dei tipici passaggi diagnostici prima di procedere con l'indagine. i registri nel profondo.

a interrompere temporaneamente un servizio perché stai eseguendo la manutenzione o semplicemente perché non ne hai bisogno per un po':

sudo systemctl stop apache2

Ciò non impedisce che si riavvii al prossimo riavvio, se abilitato. Se si desidera che scompaia completamente fino a nuovo avviso, è possibile combinare stop con disabilita la maschera a seconda del grado di "divieto" che si desidera applicare.

Dopo qualsiasi intervento chirurgico sensibile, è altamente raccomandato controllare lo stato del servizio e dei suoi ultimi record con:

sudo systemctl status nombre_servicio

E, se hai bisogno di più contesto, con journalctl, ad esempio:

sudo journalctl -u nombre_servicio

Risoluzione dei problemi comuni con systemctl

Quando qualcosa va storto quando si avvia un servizio con systemctlÈ normale vedere messaggi come "Lavoro per X fallito" o stati mancato nell'uscita di stato. Il modo ordinato per procedere è solitamente:

1. Visualizza lo stato dettagliato dell'unità:

sudo systemctl status nombre_servicio

Qui potrai vedere se il servizio non si avvia a causa di un errore di comando, un timeout, problemi di autorizzazione, un file mancante, ecc. Osserva righe come "Main PID exited" e i messaggi di errore effettivi dell'applicazione.

2. Esaminare i record completi con journalctl:

sudo journalctl -u nombre_servicio

In questo modo si ottiene la cronologia dei log generati dall'unità, il che è molto utile se il servizio "muore" subito dopo l'avvio.

3. Controlla se è abilitato quando ti aspetti che si avvii:

sudo systemctl is-enabled nombre_servicio

Se appare come disabilitato, basta:

sudo systemctl enable nombre_servicio

4. Controlla i permessi e l'utenteAlcuni servizi devono essere eseguiti da un utente specifico o accedere a percorsi specifici. Se il file di unità specifica un User= o Group= errato, o il percorso in ExecStart= Se non esiste o non è accessibile, il servizio può interrompersi all'istante.

5. Se hai modificato manualmente il file dell'unità, ricorda sempre ricarica la configurazione di systemd con:

sudo systemctl daemon-reload

Dimenticare questo passaggio è un errore classico: si apportano modifiche, si riavvia il servizio e si continua a vedere il vecchio comportamento perché systemd non ha ancora letto il nuovo file.

Mantenere questa routine di controlli e rivedere periodicamente lo stato delle unità chiave rende tutto molto più semplice. Mantenere un sistema Linux stabile e prevedibile.

Come vedi systemctl diventa il coltellino svizzero per la gestione dei servizi, delle unità e degli stati di sistema In qualsiasi distribuzione moderna con systemd, è possibile avviare e arrestare i daemon con precisione, controllare cosa viene avviato all'avvio, analizzare i bug in modo molto dettagliato, modificare le configurazioni senza sovrascrivere i file di sistema e passare dalla modalità grafica a quella di ripristino in pochi secondi. Padroneggiare questi comandi non solo semplifica notevolmente la gestione di server o desktop Linux, ma aumenta anche la sicurezza nella risoluzione di gravi problemi di produzione, perché si sa esattamente cosa è in esecuzione, perché e come interromperlo o modificarlo in modo sicuro.