Ricerca nel sito web

Come creare ed eseguire nuove unità di servizio in Systemd


Qualche giorno fa mi sono imbattuto in una distribuzione Centos 8 a 32 bit e ho sentito il desiderio di testarla su una vecchia macchina a 32 bit. Dopo l'avvio mi sono reso conto che c'era un bug e stava perdendo la connessione di rete, che dovevo attivare "su" manualmente ogni volta dopo l'avvio. Quindi, la domanda era: come potevo impostare uno script che svolgesse questo lavoro, in esecuzione ogni volta che avvio la mia macchina?

Bene, questo è molto semplice e ti mostrerò il modo in cui il sistema utilizza le unità di servizio. Ma prima una piccola introduzione alle unità di servizio.

In questo articolo spiegherò cos'è una "unità di servizio" in systemd e quanto è facile crearne ed eseguirne una. Cercherò di semplificare cosa sono gli “obiettivi”, perché li chiamiamo “raccolte di unità” e quali sono i loro “desideri”. Infine, stiamo sfruttando un'unità di servizio per eseguire il nostro script dopo la procedura di avvio.

È ovvio che il tuo computer è utile grazie ai servizi che offre e per avere questa funzionalità è necessario richiamare molti servizi quando il computer si avvia e raggiunge diversi livelli.

Altri servizi vengono chiamati per essere eseguiti quando il computer raggiunge, ad esempio, il livello di ripristino (runlevel 0) e altri quando raggiunge il livello multiutente (runlevel 3). . Puoi immaginare questi livelli come obiettivi.

In modo semplice, target è una raccolta di unità di servizio. Se vuoi dare un'occhiata alle unità di servizio in esecuzione nel tuo livello graphic.target, digita:

systemctl --type=service

Come puoi vedere, alcuni servizi sono attivi e "in esecuzione" continuamente, mentre altri vengono eseguiti una volta e terminano (chiusi).

Se vuoi controllare lo stato di un servizio, puoi usare il comando systemctl come mostrato.

systemctl status firewalld.service

Come puoi vedere ho controllato lo stato di firewalld.service (suggerimento: puoi utilizzare il completamento automatico per il nome del servizio ). Mi informa che il servizio firewalld è sempre in esecuzione ed è abilitato.

Abilitato e disabilitato significa che il servizio verrà caricato in modo permanente o meno, rispettivamente durante l'avvio successivo. D'altra parte, avviare e interrompere un servizio ha la limitazione della sessione attuale e non è permanente.

Ad esempio, se digiti:

systemctl stop firewalld.service
systemctl status firewalld.service

Puoi vedere che firewalld.service è inattivo (morto) ma è ancora abilitato, il che significa che durante il prossimo avvio verrà caricato. Quindi, se vogliamo che un servizio venga caricato durante l'avvio in futuro, dobbiamo abilitarlo. Che conclusione fantastica! Creiamone uno, è facile.

Se vai alla cartella:

cd /etc/systemd/system
ls -l

Puoi vedere alcuni file di collegamento dei servizi unitari e alcune directory dei “desideri” di un target. Ad esempio, ciò che il target multiutente vuole che venga caricato quando la procedura di avvio raggiunge il suo livello, è elencato nella directory con il nome /etc/systemd/system/multi-user.target.wants/ .

ls multi-user.target.wants/

Come puoi vedere non contiene solo servizi ma anche altri target che sono anch'essi raccolte di servizi.

Creiamo un'unità di servizio con il nome connection.service.

vim connection.service

e digita quanto segue (premi “i ” per la modalità di inserimento), salvalo ed esci (con “esc ” e “:wq! ” ) :

[Unit]
Description = making network connection up
After = network.target

[Service]
ExecStart = /root/scripts/conup.sh

[Install]
WantedBy = multi-user.target

Per spiegare quanto sopra: abbiamo creato un'unità di tipo servizio (puoi anche creare unità di tipo target) e l'abbiamo impostata per essere caricata dopo network.target (puoi capire che il la procedura di avvio raggiunge gli obiettivi con un ordine definito) e vogliamo che ogni volta che il servizio inizia esegua uno script bash con il nome conup.sh che andremo a creare.

Il divertimento inizia con l'ultima parte [installa]. Indica che sarà desiderato da “multi-user.target ”. Quindi, se abilitiamo il nostro servizio, verrà creato un collegamento simbolico a quel servizio all'interno della cartella multi-user.target.wants! Fatto? E se lo disabilitiamo, quel collegamento verrà eliminato. Così semplice.

Basta abilitarlo e controllare:

systemctl enable connection.service

Ci informa che il collegamento simbolico nella cartella multi-user.target.wants è stato creato. Puoi confermare eseguendo il comando ls come mostrato.

ls multi-user.target.wants/

Come puoi vedere, “connection.service ” è pronto per il prossimo avvio, ma dobbiamo prima creare il file di script.

cd /root
mkdir scripts
cd scripts
vim conup.sh

Aggiungi la seguente riga all'interno di Vim e salvala:

#!/bin/bash
nmcli connection up enp0s3

Il comando nmcli per attivare la connessione di rete per l'interfaccia enp0s3.

Naturalmente, se vuoi che il tuo script esegua qualcos'altro, puoi digitare quello che vuoi invece della seconda riga.

Per esempio,

#!/bin/bash
touch /tmp/testbootfile

ciò creerebbe un file nella cartella /tmp (solo per verificare che il tuo servizio funzioni).

Dobbiamo anche rendere eseguibile lo script eseguendo il comando chmod come mostrato.

chmod +x conup.sh

Ora siamo pronti. Se non vogliamo aspettare fino al prossimo avvio (è già abilitato) possiamo avviare il servizio per la sessione corrente digitando:

systemctl start connection.service

Ecco! La mia connessione è attiva e funzionante!

Se hai scelto di scrivere il comando “touch /tmp/testbootfile ” all'interno dello script, solo per verificarne la funzionalità, vedrai questo file creato all'interno della cartella /tmp .

Spero davvero di aiutarti a capire quali sono i servizi, i desideri, gli obiettivi e l'esecuzione di script durante l'avvio.