LINUX – 101.3 Modifica runlevel avvio e spegnimento

Introduzione

Una caratteristica comune tra i sistemi operativi che seguono i principi di progettazione Unix è l’impiego di processi separati per controllare funzioni distinte del sistema. Questi processi, chiamati daemon (o, più in generale, servizi ), sono anche responsabili di funzionalità estese alla base del sistema operativo, come servizi di applicazioni di rete (server HTTP, condivisione file, e-mail, ecc.), Database, configurazione su richiesta, ecc. Sebbene Linux utilizzi un kernel monolitico, molti demoni del sistema operativo sono influenzati da demoni, come il bilanciamento del carico e la configurazione del firewall.

Quali demoni dovrebbero essere attivi dipendono dallo scopo del sistema. L’insieme di daemon attivi dovrebbe anche essere modificabile in fase di esecuzione, quindi i servizi possono essere avviati e arrestati senza dover riavviare l’intero sistema. Per affrontare questo problema, ogni grande distribuzione Linux offre una qualche forma di utilità di gestione del servizio per controllare il sistema.

I servizi possono essere controllati da script di shell o da un programma e dai suoi file di configurazione di supporto. Il primo metodo è implementato dallo standard SysVinit , noto anche come System V o semplicemente SysV . Il secondo metodo è implementato da systemd e Upstart . Storicamente, i gestori di servizi basati su SysV erano i più utilizzati dalle distribuzioni Linux. Oggi, i gestori di servizi basati su systemd si trovano più spesso nella maggior parte delle distribuzioni Linux. Il service manager è il primo programma lanciato dal kernel durante il processo di avvio, quindi il suo PID (numero identificativo del processo) è sempre 1.

SysVinit

Un gestore di servizi basato sullo standard SysVinit fornirà set predefiniti di stati di sistema, chiamati runlevel e i relativi file di script di servizio da eseguire. I runlevel sono numerati 0a 6, essendo generalmente attribuita alle seguenti finalità:

Runlevel 0

Spegnimento del sistema.

Runlevel 1, se singolo

Modalità utente singolo, senza rete e altre funzionalità non essenziali (modalità manutenzione).

Runlevel 2, 3 o 4

Modalità multiutente. Gli utenti possono accedere tramite console o rete. I runlevel 2 e 4 non sono usati spesso.

Runlevel 5

Modalità multiutente. È equivalente a 3, oltre al login in modalità grafica.

Runlevel 6

Riavvio del sistema.

Il programma responsabile della gestione dei runlevel e dei demoni / risorse associati è /sbin/init. Durante l’inizializzazione del sistema, il initprogramma identifica il runlevel richiesto, definito da un parametro del kernel o nel /etc/inittabfile, e carica gli script associati ivi elencati per il runlevel specificato. A ogni runlevel possono essere associati molti file di servizio, in genere script nella /etc/init.d/directory. Poiché non tutti i runlevel sono equivalenti attraverso diverse distribuzioni Linux, una breve descrizione dello scopo del runlevel può essere trovata anche nelle distribuzioni basate su SysV.

La sintassi del /etc/inittabfile utilizza questo formato:

id: runlevel: azione: processo

Il idnome generico è composto da un massimo di quattro caratteri utilizzati per identificare la voce. La runlevelsvoce è un elenco di numeri di runlevel per i quali deve essere eseguita un’azione specifica. Il actiontermine definisce come initeseguirà il processo indicato dal termine process. Le azioni disponibili sono:

boot

Il processo verrà eseguito durante l’inizializzazione del sistema. Il campo runlevelsè ignorato.

bootwait

Il processo verrà eseguito durante l’inizializzazione del sistema e initattenderà fino al termine per continuare. Il campo runlevelsè ignorato.

sysinit

Il processo verrà eseguito dopo l’inizializzazione del sistema, indipendentemente dal runlevel. Il campo runlevelsè ignorato.

wait

Il processo verrà eseguito per i runlevel indicati e initattenderà fino al termine per continuare.

respawn

Il processo verrà riavviato se viene terminato.

ctrlaltdel

Il processo verrà eseguito quando il processo init riceve il SIGINTsegnale, attivato quando viene premuta la sequenza di tasti di Ctrl+ Alt+Del .

Il runlevel predefinito – quello che verrà scelto se nessun altro viene dato come parametro del kernel – è anche definito nella /etc/inittabvoce id:x:initdefault. Il xè il numero del runlevel di default. Questo numero non dovrebbe mai essere 0o 6, dato che causerebbe l’arresto o il riavvio del sistema non appena termina il processo di avvio. Di /etc/inittabseguito è mostrato un file tipico :

# Runlevel predefinito

id: 3: initdefault:

# Script di configurazione eseguito durante l’avvio

si :: sysinit: /etc/init.d/rcS

# Azione intrapresa sul runlevel S (utente singolo)

~: S: wait: / sbin / sulogin

# Configurazione per ogni livello di esecuzione

l0: 0: wait: /etc/init.d/rc 0

l1: 1: wait: /etc/init.d/rc 1

l2: 2: wait: /etc/init.d/rc 2

l3: 3: wait: /etc/init.d/rc 3

l4: 4: wait: /etc/init.d/rc 4

l5: 5: wait: /etc/init.d/rc 5

l6: 6: attendere: /etc/init.d/rc 6

# Azione intrapresa su ctrl + alt + del tasto

ca :: ctrlaltdel: / sbin / shutdown -r ora

# Abilita le console per i runlevel 2 e 3

1: 23: respawn: / sbin / getty tty1 VC linux

2: 23: respawn: / sbin / getty tty2 VC linux

3: 23: respawn: / sbin / getty tty3 VC linux

4: 23: respawn: / sbin / getty tty4 VC linux

# Per runlevel 3, abilitare anche seriale

# terminali console ttyS0 e ttyS1 (modem)

S0: 3: respawn: / sbin / getty -L 9600 ttyS0 vt320

S1: 3: respawn: / sbin / mgetty -x0 -D ttyS1

Il telinit qcomando deve essere eseguito ogni volta che il /etc/inittabfile viene modificato. L’argomento q(o Q) dice a init di ricaricare la sua configurazione. Tale passaggio è importante per evitare l’arresto del sistema a causa di una configurazione errata in /etc/inittab.

Gli script utilizzati initper impostare ciascun runlevel sono memorizzati nella directory /etc/init.d/. Ogni runlevel ha una directory associata a /etc/, nome /etc/rc0.d/, /etc/rc1.d/, /etc/rc2.d/, ecc, con gli script che dovrebbe essere eseguito quando il corrispondente inizia a runlevel. Poiché lo stesso script può essere utilizzato da runlevel diversi, i file in quelle directory sono solo collegamenti simbolici agli script effettivi in /etc/init.d/. Inoltre, la prima lettera del nome file del collegamento nella directory del runlevel indica se il servizio deve essere avviato o terminato per il runlevel corrispondente. Il nome file di un collegamento che inizia con una lettera Kdetermina che il servizio verrà ucciso quando si accede al runlevel (kill). A partire dalla letteraS, il servizio verrà avviato quando si accede al runlevel (inizio). La directory /etc/rc1.d/, ad esempio, avrà molti collegamenti agli script di rete che iniziano con la lettera K, considerando che il runlevel 1 è il runlevel per singolo utente, senza connettività di rete.

Il comando runlevelmostra il runlevel corrente per il sistema. Il runlevelcomando mostra due valori, il primo è il runlevel precedente e il secondo è il runlevel corrente:

$ runlevel

N 3

La lettera Nnell’output mostra che il runlevel non è cambiato dall’ultimo avvio. Nell’esempio, runlevel 3è l’attuale runlevel del sistema.

Lo stesso initprogramma può essere utilizzato per alternare i runlevel in un sistema in esecuzione, senza la necessità di riavviare. Il comando telinitpuò anche essere usato per alternare i runlevel. Ad esempio, i comandi telinit 1, telinit so telinit Scambierà il sistema al runlevel 1.

systemd

Attualmente, systemd è il set di strumenti più utilizzato per gestire risorse e servizi di sistema, che vengono definiti unità da systemd. Un’unità è composta da un nome, un tipo e un file di configurazione corrispondente. Ad esempio, l’unità per un processo del server httpd (come il web server Apache) sarà httpd.servicesu distribuzioni basate su Red Hat e verrà anche chiamato httpd.serviceil suo file di configurazione (sulle distribuzioni basate su Debian questa unità è denominata apache2.service).

Esistono sette tipi distinti di unità systemd:

service

Il tipo di unità più comune, per risorse di sistema attive che possono essere avviate, interrotte e ricaricate.

socket

Il tipo di unità socket può essere un socket del filesystem o un socket di rete. Tutte le unità presa hanno un’unità di servizio corrispondente, caricata quando la presa riceve una richiesta.

device

Un’unità dispositivo è associata a un dispositivo hardware identificato dal kernel. Un dispositivo verrà preso come unità di sistema solo se esiste una regola udev per questo scopo. Un’unità dispositivo può essere utilizzata per risolvere le dipendenze di configurazione quando viene rilevato un determinato hardware, dato che le proprietà della regola udev possono essere utilizzate come parametri per l’unità dispositivo.

mount

Un’unità di mount è una definizione del punto di mount nel filesystem, simile a una voce in /etc/fstab.

automount

Un’unità di montaggio automatico è anche una definizione del punto di montaggio nel filesystem, ma montata automaticamente. Ogni unità di montaggio automatico ha un’unità di montaggio corrispondente, che viene avviata quando si accede al punto di montaggio di montaggio automatico.

target

Un’unità bersaglio è un raggruppamento di altre unità, gestite come una singola unità.

snapshot

Un’unità snapshot è uno stato salvato del gestore di sistema (non disponibile su ogni distribuzione Linux).

Il comando principale per il controllo delle unità di sistema è systemctl. Il comando systemctlviene utilizzato per eseguire tutte le attività relative all’attivazione, disattivazione, esecuzione, interruzione, monitoraggio dell’unità, ecc. Per un’unità fittizia chiamata unit.service, ad esempio, le systemctlazioni più comuni saranno:

systemctl start unit.service

Inizia unit.

systemctl stop unit.service

Si ferma unit.

systemctl restart unit.service

Riavvia unit.

systemctl status unit.service

Mostra lo stato di unit, incluso se è in esecuzione o meno.

systemctl is-active unit.service

Mostra attivo se unitè in esecuzione o inattivo altrimenti.

systemctl enable unit.service

Abilita unit, ovvero unitverrà caricato durante l’inizializzazione del sistema.

systemctl disable unit.service

unit non inizierà con il sistema.

systemctl is-enabled unit.service

Verifica se unitinizia con il sistema. La risposta è memorizzata nella variabile $?. Il valore 0indica che unitinizia con il sistema e il valore 1indica che unitnon inizia con il sistema.

Se non esistono altre unità con lo stesso nome nel sistema, è possibile eliminare il suffisso dopo il punto. Se, ad esempio, esiste una sola httpdunità di tipo service, allora httpdè sufficiente solo il parametro unitario per systemctl.

Il systemctlcomando può anche controllare i target di sistema . L’ multi-user.targetunità, ad esempio, combina tutte le unità richieste dall’ambiente di sistema multiutente. È simile al runlevel numero 3 in un sistema che utilizza SysV.

Il comando si systemctl isolatealterna tra target diversi. Quindi, per alternare manualmente al target multi-user:

# systemctl isolare multi-user.target

Esistono obiettivi corrispondenti ai runlevel SysV, a partire da runlevelO.targetfino a runlevel6.target. Tuttavia, systemd non utilizza il /etc/inittabfile. Per modificare la destinazione di sistema predefinita, è systemd.unitpossibile aggiungere l’opzione all’elenco dei parametri del kernel. Ad esempio, per usare multi-user.targetcome target standard, il parametro kernel dovrebbe essere systemd.unit=multi-user.target. Tutti i parametri del kernel possono essere resi persistenti modificando la configurazione del bootloader.

Un altro modo per cambiare la destinazione predefinita è modificare il collegamento simbolico in /etc/systemd/system/default.targetmodo che punti alla destinazione desiderata. La ridefinizione del collegamento può essere fatta con il systemctlcomando da sola:

# systemctl set-default multi-user.target

Allo stesso modo, puoi determinare quale sia la destinazione di avvio predefinita del tuo sistema con il seguente comando:

$ systemctl get-default

graphical.target

Simile ai sistemi che adottano SysV, la destinazione predefinita non dovrebbe mai puntare shutdown.target, poiché corrisponde al runlevel 0 (arresto).

I file di configurazione associati a ogni unità sono disponibili nella /lib/systemd/system/directory. Il comando systemctl list-unit-fileselenca tutte le unità disponibili e mostra se sono abilitate per l’avvio all’avvio del sistema. L’opzione –typeselezionerà solo le unità per un determinato tipo, come in systemctl list-unit-files –type=servicee systemctl list-unit-files –type=target.

Le unità attive o che sono state attive durante la sessione di sistema corrente possono essere elencate con il comando systemctl list-units. Come l’ list-unit-filesopzione, il systemctl list-units –type=servicecomando selezionerà solo le unità di tipo servicee il comando systemctl list-units –type=targetselezionerà solo le unità di tipo target.

systemd è anche responsabile dell’attivazione e della risposta agli eventi correlati all’alimentazione. Il systemctl suspendcomando metterà il sistema in modalità a basso consumo, mantenendo i dati correnti in memoria. Il comando systemctl hibernatecopierà tutti i dati della memoria su disco, quindi lo stato corrente del sistema può essere ripristinato dopo averlo spento. Le azioni associate a tali eventi sono definite nel file /etc/systemd/logind.confo in file separati all’interno della directory /etc/systemd/logind.conf.d/. Tuttavia, questa funzione di systemd può essere utilizzata solo quando nel sistema non è in esecuzione nessun altro power manager, come il acpiddemone. Il acpiddaemon è il principale power manager per Linux e consente regolazioni più precise delle azioni a seguito di eventi correlati all’alimentazione, come la chiusura del coperchio del laptop, la batteria scarica o i livelli di carica della batteria.

parvenu

Gli script di inizializzazione utilizzati da Upstart si trovano nella directory /etc/init/. I servizi di sistema possono essere elencati con il comando initctl list, che mostra anche lo stato corrente dei servizi e, se disponibile, il loro numero PID.

# lista initctl

avahi-cups-ricaricare stop / attesa

avahi-daemon start / running, processo 1123

mountall-net stop / attesa

mountnfs-bootclean.sh start / running

nmbd start / running, process 3085

passwd stop / attesa

rc stop / in attesa

rsyslog start / running, process 1095

tty4 start / running, processo 1761

udev start / running, process 1073

upstart-udev-bridge start / running, processo 1066

arresto / attesa della configurazione della console

avvio / esecuzione irqbalance, processo 1842

plymouth-log stop / in attesa

avvio / esecuzione smbd, processo 1457

tty5 start / running, process 1764

arresto / attesa fail-safe

Ogni azione Upstart ha il suo comando indipendente. Ad esempio, il comando startpuò essere utilizzato per avviare un sesto terminale virtuale:

# start tty6

Lo stato corrente di una risorsa può essere verificato con il comando status:

# status tty6

tty6 start / running, processo 3282

E l’interruzione di un servizio viene eseguita con il comando stop:

# stop tty6

Upstart non utilizza il /etc/inittabfile per definire i runlevel, ma i comandi legacy runlevele telinitpuò ancora essere utilizzato per verificare e alternare tra i runlevel.

Arresto e riavvio

Un comando molto tradizionale utilizzato per arrestare o riavviare il sistema viene chiamato in modo non sorprendente shutdown. Il shutdowncomando aggiunge funzioni extra al processo di spegnimento: avvisa automaticamente tutti gli utenti che hanno effettuato l’accesso con un messaggio di avviso nelle loro sessioni di shell e vengono impediti nuovi accessi. Il comando shutdownfunge da intermediario per le procedure SysV o systemd, ovvero esegue l’azione richiesta chiamando l’azione corrispondente nel gestore servizi adottato dal sistema.

Dopo l’ shutdownesecuzione, tutti i processi ricevono il SIGTERMsegnale, seguito dal SIGKILLsegnale, quindi il sistema si spegne o cambia il suo runlevel. Per impostazione predefinita, quando non vengono utilizzate né opzioni -hné -r, il sistema si alterna al livello di esecuzione 1, ovvero alla modalità utente singolo. Per modificare le opzioni predefinite per shutdown, il comando deve essere eseguito con la sintassi seguente:

$ shutdown [opzione] tempo [messaggio]

È timerichiesto solo il parametro . Il timeparametro definisce quando verrà eseguita l’azione richiesta, accettando i seguenti formati:

hh:mm

Questo formato specifica il tempo di esecuzione come ora e minuti.

+m

Questo formato specifica quanti minuti attendere prima dell’esecuzione.

now o +0

Questo formato determina l’esecuzione immediata.

Il messageparametro è il testo di avviso inviato a tutte le sessioni del terminale degli utenti che hanno effettuato l’accesso.

L’implementazione di SysV consente di limitare gli utenti che saranno in grado di riavviare la macchina premendo Ctrl+ Alt+Del . Ciò è possibile inserendo l’opzione -aper il shutdowncomando presente nella riga relativa ctrlaltdelal /etc/inittabfile. In questo modo, solo gli utenti i cui nomi utente sono presenti nel /etc/shutdown.allowfile saranno in grado di riavviare il sistema con la combinazione di tasti Ctrl+ Alt+Del .

Il systemctlcomando può anche essere utilizzato per spegnere o riavviare la macchina nei sistemi che utilizzano systemd. Per riavviare il sistema, è systemctl rebootnecessario utilizzare il comando . Per spegnere il sistema, è systemctl poweroffnecessario utilizzare il comando . Entrambi i comandi richiedono l’esecuzione dei privilegi di root, poiché gli utenti ordinari non possono eseguire tali procedure.

Non tutte le attività di manutenzione richiedono che il sistema sia spento o riavviato. Tuttavia, quando è necessario modificare lo stato del sistema in modalità utente singolo, è importante avvisare gli utenti che hanno effettuato l’accesso in modo che non vengano danneggiati da una brusca interruzione delle loro attività.

Simile a quello che fa il shutdowncomando quando si spegne o si riavvia il sistema, il wallcomando è in grado di inviare un messaggio alle sessioni terminali di tutti gli utenti che hanno effettuato l’accesso. Per fare ciò, l’amministratore di sistema deve solo fornire un file o scrivere direttamente il messaggio come parametro da comandare wall.

Vuoi abilitare le notifiche?

Desiderate avere la possibilita’ di ricevere delle notifiche? Se si avrete la possibilita’ di essere sempre aggiornati con le nostre ultime proposte o notizie . Consigliamo l’adesione Grazie !

Attiva