Iniziamo a creare il file di configurazione in /usr/lib/systemd/system/ chiamato testService.service e scriviamoci:
Cerchiamo di capire le varie entry inserite nel file di configurazione:
Come configurare i servizi in Linux con systemd
In questo articolo spiegherò come configurare un servizio linux utilizzando systemd; voglio anticipare che non mi soffermerò in spiegazioni architetturali o teoriche, perciò se voleste saperne di più potrete sempre dare un occhio a questo articolo. Voglio precisare che ho scelto di spiegare systemd, perché lo uso e perché rispetto ad ad altri gestori, è decisamente più performante. Sollo a scopo riassuntivo vi riporto uno schema generale dell’architettura che non commenterò.
Prima di iniziare, pertanto, a capire come configurare un nuovo servizio, proviamo ad imparare qualche comando utile per la gestione dei servizi.
Lista dei comandi systemd a nostra disposizione
1) Per avviare un servizio
systemctl start SERVICE
N.B al reboot in tal caso il servizio dovrà essere riavviato manualmente.
2) per stoppare un servizio:
systemctl stop SERVICE
3) per riavviare un servizio
systemctl restart SERVICE
4) Per effettuare il reload delle configurazione la dove previsto nel servizio, senza interruzione dello stesso.
systemctl reload SERVICE
5) Per conoscere lo stato del servizio
systemctl status SERVICE
6) Per attivare il servizio e renderlo disponibile al successivo riavvio.
systemctl enable SERVICE
7) Per disattivare il servizio e non renderlo disponibile al successivo riavvio.
systemctl disable SERVICE
8) Per verificare se un servizio è configurato correttamente ed enable
systemctl is-enabled SERVICE
9) Per verificare se un servizio è in running/ attivo
systemctl is-active SERVICE
10) Per avere tutte le informazioni generali sul servizio
systemctl show SERVICE
11) Per disabilitare completamente un servizio collegandolo a /dev/null
sudo systemctl mask SERVICE
12) Per rimuove il collegamento /dev/null e ripristinare la possibilità di abilitare e / o avviare manualmente il servizio.
sudo systemctl unmask SERVICE
A questo punto abbiamo gli strumenti per gestire l’attivazione dei servizi, pertanto è arrivato il momento di capire come inizializzare un nuovo servizio che chiameremo testService che attiverà un generico script, ad esempio, scritto in python “test.py”
Per il nostro scopo supponiamo di salvare i nostri script in una WorkingDirectory a scelta, nel mio caso userò /work
In prima istanza facciamo caso che abbiamo definito il nome del servizio come .service. In systemd il concetto di servizio, infatti, ha una accezione molto ampia ed connessa al concetto di units, le quali, infatti, ci consentono di astrarre servizi, risorse di rete, dispositivi, file system etc. Di seguito una lista delle opzioni a nostra disposizione:
|
.service: unit che descrive come gestire un servizio o un’applicazione sul server ed includerà come avviare o arrestare il servizio ed in quali circostanze dovrebbe essere avviato automaticamente.
.socket: unit che descrive un socket di rete o IPC o un buffer FIFO che systemd utilizza per l’attivazione basata su socket. A questo tipo di unit è sempre associato un file .service che verrà avviato quando sulla socket viene inizializzata l’attività definita da questa unità.
.device: unit che descrive un dispositivo di systemd. L’uso della unit .device si configura nei casi in cui potrebbe essere necessario montare ed accedere ai dispositivi.
.mount: questa unità definisce un mountpoint sul sistema che deve essere gestito da systemd.
.automount: configura un mountpoint che verrà montato automaticamente.
.swap: questa unità descrive lo spazio di swap sul sistema. Il nome di queste unità deve riflettere il percorso del dispositivo o del file dello spazio.
.target: un’unità target viene utilizzata per fornire punti di sincronizzazione per altre unità quando si avvia o si cambia stato.
.path: questa unità definisce un path che può essere utilizzato per l’attivazione del servizio.
.timer: un’unità .timer definisce un timer che verrà gestito da systemd, in modo simile a un cron job per l’attivazione ritardata o programmata. La unit corrispondente verrà avviata al raggiungimento del timer.
.snapshot: un’unità .snapshot viene creata automaticamente dal comando snapshot di systemctl. Ti consente di ricostruire lo stato corrente del sistema dopo aver apportato modifiche.
.slice: un’unità .slice è associata ai nodi del gruppo di controllo Linux, consentendo alle risorse di essere limitate o assegnate a tutti i processi associati alla sezione.
.scope è utilizzata per gestire set di processi di sistema creati esternamente.
|
Ritorniamo al nostro esempio.
[Unit]
Nella sezione unit vengono definiti gli oggetti che systemd dovrà gestire, quindi il cosa ed il come.
Description è la property che descrive un nome generico per il servizio
After=multi-user.target questa riga indica al sistema quando avviare lo script. In questo caso (con la direttiva multi-user.target) informiamo systemd di avviarlo quando il sistema è pronto, dopo il boot, per il login degli utenti. E’ la situazioni tipica per avviare uno script dopo l’avvio del sistema
[Service]
è la sezione dedicata ai dettagli del servizio, di cui analizziamo di seguito alcune possibilità:
Type è la modalità con cui il servizio viene eseguito. simple indica che si tratta di un normale servizio, oneshot indica di eseguire uno script ed uscire. Altre opzioni a nostra disposizione ed ulteriori dettagli potete trovarli qui.
ExecStart da indicazioni sul comando da eseguire, nel nostro caso lo script Python
User opzionale, specifica l’utente con cui eseguire lo script, altrimenti viene lanciato con l’utente root
WorkingDirectory opzionale, serve per specificare il runtime environment, eseguendo lo script in una cartella specifica. E’ utile se lo script deve leggere un file, perché la posizione sarà relativa proprio a questa impostazione, piuttosto che dover indicare un percorso assoluto.
Restart= always indica a systemd di riavviare sempre il servizio qualora esso non fosse più in running, mentre ad esempio Restart=on-failure indica a systemd che lo script venga riavviato in caso di fault. In questo pagina del man potete trovare la lista completa dei possibili valori.
[Install] è la sezione in cui si indica quando il servizio andrà eseguito.
WantedBy=multi-user.target è una riga ridondante che specifica di installare il servizio nel multi-user.target boot level.
Sono amante della tecnologia e delle tante sfumature del mondo IT, ho partecipato, sin dai primi anni di università ad importanti progetti in ambito Internet proseguendo, negli anni, allo startup, sviluppo e direzione di diverse aziende; Nei primi anni di carriera ho lavorato come consulente nel mondo dell’IT italiano, partecipando attivamente a progetti nazionali ed internazionali per realtà quali Ericsson, Telecom, Tin.it, Accenture, Tiscali, CNR. Dal 2010 mi occupo di startup mediante una delle mie società techintouch S.r.l che grazie alla collaborazione con la Digital Magics SpA, di cui sono Partner la Campania, mi occupo di supportare ed accelerare aziende del territorio .
Attualmente ricopro le cariche di :
– CTO MareGroup
– CTO Innoida
– Co-CEO in Techintouch s.r.l.
– Board member in StepFund GP SA
Manager ed imprenditore dal 2000 sono stato,
CEO e founder di Eclettica S.r.l. , Società specializzata in sviluppo software e System Integration
Partner per la Campania di Digital Magics S.p.A.
CTO e co-founder di Nexsoft S.p.A, società specializzata nella Consulenza di Servizi in ambito Informatico e sviluppo di soluzioni di System Integration, CTO della ITsys S.r.l. Società specializzata nella gestione di sistemi IT per la quale ho partecipato attivamente alla fase di startup.
Sognatore da sempre, curioso di novità ed alla ricerca di “nuovi mondi da esplorare“.
Se vuoi farmi qualche richiesta o contattarmi per un aiuto riempi il seguente form
Comments