• Guide, Open Source
• 4 Settembre 2016

Possiamo definire “servizio” un processo, o un insieme di processi, che può funzionare su un sistema indipendentemente dall’attività dell’utente. Su un qualsiasi client Windows, ad esempio, troviamo i servizi per gestire l’assegnazione automatica di un indizzo ip (dhcp client), per indicizzare i files in modo da facilitare le ricerche (Windows search), per proteggere le connessioni verso la nostra macchina (Firewall), analizzare file potenzialmente dannosi (Windows Defender), e così via…

Tutte queste funzionalità, ed ovviamente molte altre, sono presenti su una macchina anche se nessun utente la sta utilizzando, e costituiscono una componente molto importante nell’architettura di un sistema operativo poiché è proprio grazie ad esse che sarà possibile effettuare o meno delle attività sul sistema stesso.

E’ chiaramente possibile installare e rimuovere servizi per aumentare o diminuire le funzionalità attive sulla nostra macchina, e siamo sempre stati abituati a gestire il loro avvio su una macchina Windows utlilzzando il comando net dal prompt dei comandi DOS, aprendo la gestione dei servizi da Pannello di controllo o eseguendo services.msc dal menu avvio.

Utilizzando questa management console, ad esempio, è sufficiente visualizzare le proprietà di ogni servizio per avviarlo, fermarlo, oppure indicare se il servizio stesso dovrà partire automaticamente all’avvio del sistema, o dovrà essere avviato manualmente.

Con l’introduzione di Windows Subsystem for Linux (https://www.ictpower.it/sistemi-operativi/windows-subsystem-for-linux-finalmente-in-una-release-ufficiale.htm) la situazione si complica un po’, perché tutti i servizi che sono presenti sul sottosistema Linux non sono gestibili attraverso questa console, ma si comportano proprio come farebbero su un sistema Linux nativo.

Per comprendere la gestione dei servizi in un sistema Linux è necessario introdurre il concetto di runlevel. Il runlevel indica lo stato in cui si trova il sistema operativo relativamente all’utilizzo o meno dei servizi, e viene indicato attraverso un numero intero. I runlevel principali sono rappresentati nell’elenco seguente:

0 – Rappresenta lo stato di totale inattività della macchina con nessun processo in esecuzione. Questo stato si verifica in un unico caso: la macchina è spenta

1 (Single user mode) – Utilizzato unicamente per fini diagnostici, è lo stato del sistema in cui è attiva una minima parte del sistema operativo, senza nessun servizio attivo; l’accesso è consentito solo all’amministratore.

2 – La macchina è in modalità multiutente con il networking abilitato ma senza servizi attivi

3 – La macchina è in modalità multiutente con il networking abilitato ed i servizi attivi ad esclusione del server grafico. Il sistema è utilizzabile unicamente da riga di comando

4 – Non utilizzato

5 – Corrisponde al level 3 con l’aggiunta del server grafico

6 – Rappresenta l’azione di chiusura dei servizi e riavvio della macchina

Le operazioni che il sistema effettua per ogni runlevel sono sempre modificabili, poiché per ogni servizio è possibile scegliere su quale runlevel deve essere attivo. Su una macchina linux è interessante notare che possiamo scegliere di avviare il sistema con runlevel 3 oppure 5 a seconda se vogliamo utilizzare la command line oppure il server grafico.

Su una macchina Linux della distribuzione Ubuntu, e quindi sul sottosistema Linux della nostra macchina Windows la gestione dei servizi è affidata a degli script. Nel momento in cui un servizio viene installato viene automaticamente generato uno script per l’avvio/arresto del servizio stesso e posizionato nella cartella /etc/init.d

In questa cartella, quindi, troveremo tutti gli script per la gestione dei servizi presenti sulla macchina, dove ogni script è un file di testo contenente i comandi necessari per avviare, fermare, o conoscere lo stato di un particolare servizio. Il nome del file è uguale al nome del servizio a cui si riferisce, e generalmente non ha estensione. Vediamo il contenuto della cartella /etc/init.d della mia macchina di esempio.

Come è possibile notare, troviamo gli script apache2 e mysql che servono a gestire il webserver ed il database server che abbiamo installato in precedenza (https://www.ictpower.it/guide/apache-php-e-mysql-su-windows-subsystem-for-linux-e-possibile.htm).

Per richiamare l’esecuzione dello script possiamo scegliere se lanciarlo direttamente (con l’opportuna azione) richiamandone il path completo in questo modo

/etc/init.d/nomescript azione

oppure utilizzare il comando service come scorciatoia. Il risultato finale sarà lo stesso:

service nomescript azione

per vedere le azioni disponibili lanciamo uno dei due senza alcuna azione, ad esempio

service nomescript

E’ chiaro che alcune azioni come ad esempio start e stop saranno valide per tutti gli script, altre (in questo caso ad esempio start-htcacheclean) saranno relative solo al servizio di riferimento. Per conoscere lo stato di un servizio utilizziamo il comando

service nomescript status

Vediamo qualche esempio di azioni lanciate sui nostri servizi apache2 e mysql:

Ribadiamo ancora una volta che stiamo lavorando su una funzionalità beta, ed anche in questo caso al momento dell’avvio dei servizi riceviamo dei warning o degli errori, che però abbiamo notato non comprometterne le funzionalità.

Nella cartella /etc esistono poi le sottocartelle che si occupano di gestire l’avvio dei servizi nei vari runlevel, ed esiste una cartella per ogni runlevel. All’interno di queste, posizionate in /etc/rcX.d doveX è il runlevel, troviamo i link agli script per far partire i servizi relativi a quel runlevel. Tralascerò il dettaglio sulla gestione di queste cartelle per il motivo che capirete tra pochissimo.

Su una distribuzione Ubuntu “reale” esiste un comando per la gestione dell’avvio dei servizi, ed è sufficiente eseguire con privilegi di amministratore (utente root):

update-rc.d nomeservizio enable

per abilitare il servizio all’avvio automatico, oppure

update-rc.d nomeservizio disable

per disabilitarlo.

Per Windows Subsystem for Linux, però, le cose non stanno proprio così; il sottosistema linux viene richiamato solo all’avvio del processo bash.exe, e fermato non appena l’esecuzione di bash termina. Gli script di avvio non vengono, quindi, processati all’avvio della macchina, e per l’avvio automatico dei servizi del sottosistema linux sarà necessario richiamarne l’esecuzione durante l’avvio di Windows.

Lanciando da un prompt di DOS il comando:

bash.exe –c "/etc/init.d/apache2 start"

siamo, ad esempio, in grado di avviare il webserver.

Per automatizzare il comando al logon dell’utente è necessario quindi creare un batch ed includerlo in esecuzione automatica, o al momento attendere speranzosi che in una prossima versione di WSL ci sia qualche interazione con i servizi di Windows.

Nel frattempo godiamoci il nostro ambiente-studio e continuiamo ad esplorarne tutte le possibiltà.