La gestione dei servizi è una responsabilità chiave per gli amministratori di sistema. Non c'è dubbio che la transizione tra il vecchio metodo SysV (usando il service e chkconfig comandi) e il più recente systemd -comandi basati su (come systemctl ) è stato controverso. In effetti, molti amministratori di sistema hanno ancora sentimenti molto forti in un modo o nell'altro.
La realtà è che molte distribuzioni, inclusa Red Hat Enterprise Linux (RHEL), hanno iniziato a gestire i servizi con systemd . Quindi, tu ed io dobbiamo sapere come lavorare con systemctl comando di gestione.
Non sono il tipo di autore/formatore/amministratore che presume che tutti siano avanzati. Con questo in mente, indirizzerò questo articolo alle persone che hanno bisogno di una spiegazione semplice e fondamentale su come e quando usare il più comune systemctl sottocomandi. Alla fine, fornisco anche un ottimo trucco per visualizzare rapidamente tutto il systemctl sottocomandi.
Nota:la pagina man di systemctl si riferisce alla seconda parola nella stringa come "comando", il che sembra alquanto confuso. Mi riferirò a systemctl stesso come un comando , quindi la stringa che la segue come sottocomando . L'argomento è il nome del servizio e occupa la terza posizione nella sintassi.
Ecco un esempio di sintassi:
systemctl subcommand argument
# systemctl status sshd
Ti mostrerò come e quando usare systemctl . La maggior parte dei miei esempi usa il comune sshd servizio.
[ I lettori hanno apprezzato anche: Come ho imparato a smettere di preoccuparmi e ad amare il sistemad ]
Stato del servizio
Il miglior punto di partenza è comprendere le attuali funzionalità del servizio. Inizierò con l'approccio più semplice, l'uso dello status sottocomando:
# systemctl status sshd 
Ovviamente, l'idea è che ti sei appena seduto su un server Linux sconosciuto e devi conoscere lo stato attuale di sshd servizio. Nota che vengono fornite molte altre informazioni, inclusa una sinossi del servizio, da dove è stato caricato, stato, ID processo (PID) e modifiche recenti.
Lo systemctl status Il comando è utile anche durante la risoluzione dei problemi. Durante la risoluzione dei problemi di una configurazione, ne verifico quasi immediatamente lo stato utilizzando systemctl . Perché preoccuparsi di firewall, SELinux e file di configurazione se il servizio non è nemmeno in esecuzione?
Quindi, ora sai come controllare lo stato di servizi come SSH. Come manipoli questo stato?
Avvio e arresto dei servizi
Quando modifichi un file di configurazione per un servizio in esecuzione, devi riavviare o ricarica il servizio. In questo modo il servizio rilegge il file e quindi implementa le modifiche. In passato utilizzavi il service comando, come negli esempi seguenti:
# service sshd restart
Servizi in systemd sono gestiti tramite il systemctl comando. Per riavviare il servizio SSH con systemctl , inserisci:
# systemctl restart sshd Personalmente, trovo questa sintassi un po' più semplice. Si legge quasi come una frase:"Systemctl, per favore riavvia sshd."
La sintassi è simile se vuoi interrompere o avviare un servizio:
# systemctl stop sshd
# systemctl start sshd
I servizi che si rifiutano di interrompersi con grazia possono essere eliminati utilizzando systemctl , anche. Ad esempio, per uccidere sshd servizio, inserisci:
# systemctl kill sshd
I servizi di ricarica sono leggermente diversi. Il reload il sottocomando fa sì che il servizio rilegga solo il file di configurazione, mentre il restart il sottocomando termina tutte le connessioni correnti e rilegge il file di configurazione.
Ad esempio, se digiti systemctl restart sshd , tutte le connessioni SSH correnti vengono eliminate. Se lo ricarichi, tuttavia, le connessioni esistenti vengono mantenute. In entrambi i casi, il file di configurazione viene riletto e le eventuali modifiche vengono implementate.
La ricarica provoca meno tempi di inattività, ma non tutti i servizi lo supportano.
L'start , stop , restart, e reload i sottocomandi influiscono solo sul runtime corrente.
Abilita e disabilita i servizi
Molti amministratori che non conoscono Linux sono confusi sulla differenza tra start /stop e enable /disable . Ho già discusso di start , stop e restart nella sezione precedente. Start e stop vengono utilizzati per modificare lo stato corrente del servizio. Tuttavia, se il server si riavvia, lo stato del servizio tornerà a qualunque sia l'impostazione di avvio predefinita. In altre parole, se interrompo sshd service e quindi riavviare il mio server, il processo di avvio esaminerà il file di configurazione e avvierà o meno sshd , a seconda di quanto specificato. Se interrompo il servizio e quindi riavvio, e il file di configurazione dice di avviare il servizio all'avvio, sarà di nuovo in esecuzione.
In precedenza, hai usato chkconfig comando per definire l'impostazione di avvio del servizio per ogni runlevel. Ecco un esempio:
# chkconfig --level 35 sshd on
Questo comando abilita sshd per l'avvio nei runlevel 3 e 5.
Con systemctl , la configurazione dell'impostazione di avvio predefinita è opera di enable e disable sottocomandi. La sintassi è la stessa di start , stop e restart sottocomandi. Ad esempio, per impostare l'avvio di SSH all'avvio del server, immettere:
# systemctl enable sshd Allo stesso modo, per configurare SSH non per iniziare durante l'avvio, digitare:
# systemctl disable sshd La configurazione della configurazione di avvio predefinita per i servizi è semplice, così come l'avvio e l'arresto dei servizi. Tuttavia, sembra esserci una certa confusione sull'utilizzo dei due insieme.
Utilizza start e abilita insieme
Alcuni trovano strano che l'abilitazione di un servizio non lo avvii. Ad esempio, se hai appena scaricato un nuovo programma e vuoi avviarlo in modo da poterne testare le funzionalità e vuoi configurarlo per l'avvio all'avvio del server, devi inserire due comandi:
# systemctl start sshd
# systemctl enable sshd 
La disabilitazione di un servizio avviene allo stesso modo. Digita systemctl disable sshd per impedire l'avvio di SSH all'avvio del server. Tuttavia, se SSH è in esecuzione nel runtime corrente, rimane attivo, anche se disabilitato. Devi stop SSH per disattivarlo nel runtime corrente.
Ad esempio, per interrompere SSH e impedirne l'avvio all'avvio del sistema, immettere:
# systemctl stop sshd
# systemctl disable sshd 
Ricordati di controllare lo status del servizio ogni volta che non sei sicuro inserendo:
# systemctl status sshd
Puoi verificare se un servizio è configurato per l'avvio automatico utilizzando un altro systemctl sottocomando:is-enabled . Ad esempio, per visualizzare se SSH è abilitato, immettere:
# systemctl is-enabled sshd 
Tanti sottocomandi:il trucco
Ho trattato un bel po' di systemctl sottocomandi, incluso start , stop , restart , enable , disable , status , e altri. È molto da ricordare! È qui che entra in gioco il completamento della scheda del tuo vecchio amico. Prova la seguente tecnica sul tuo sistema:digita systemctl e quindi aggiungi un singolo spazio. Premi la scheda due volte e bash mostra tutti i systemctl disponibili sottocomandi! Questo trucco per il completamento delle schede è uno di cui penso che pochi amministratori di sistema traggano abbastanza vantaggio.
[ Vuoi testare le tue capacità di amministratore di sistema? Fai una valutazione delle abilità oggi. ]
Concludi
Come puoi vedere, la gestione dei servizi tramite il systemctl il comando non è davvero così difficile. Lo trovo più semplice e logico del vecchio service e chkconfig comandi, personalmente. È anche comodo avere un solo comando per gestire i servizi invece di due.
Ecco i punti chiave da ricordare:
- Utilizza start/stop/restart per gestire il runtime corrente.
- Utilizza start/stop/restart/reload dopo aver modificato i file di configurazione.
- Utilizza abilita/disabilita per gestire l'azione di avvio predefinita.
- Utilizza lo stato molto presto nel processo di risoluzione dei problemi.
Infine, non devi memorizzare tutto il systemctl disponibile sottocomandi. Inserisci semplicemente il systemctl comando e seguilo con uno spazio, quindi premi Tab due volte. La funzione di completamento delle schede integrata di Bash fa il resto!
Gli amministratori di sistema si trovano regolarmente a manipolare i servizi e, si spera, tu sia un po' più a tuo agio con quando usare il più comune systemctl sottocomandi.