systemd scadente ha avuto la sua parte di detrattori, ma sembra essere qui per rimanere per gli amministratori di Linux, quindi potremmo anche abituarci. Questo pratico systemd il riferimento ai comandi ti aiuterà a mantenere la tua sanità mentale quando provi a svolgere normali attività amministrative. Quindi, finché non otteniamo qualcosa che sia più utilizzabile, appetibile e desiderabile di systemd , goditi questo elenco di dieci pratici comandi per tua comodità. Questi comandi non sono in un particolare ordine di importanza o pertinenza.
Elenca i file delle unità
Dal systemd pagina man:Un file unit è un file in stile ini di testo semplice che codifica le informazioni su un servizio, un socket, un dispositivo, un punto di montaggio, un punto di montaggio automatico, un file di scambio o una partizione, una destinazione di avvio, un file controllato percorso di sistema, un timer controllato e supervisionato da systemd , una sezione di gestione delle risorse o un gruppo di processi creati esternamente.
$ systemctl list-unit-files
UNIT FILE STATE
proc-sys-fs-binfmt_misc.automount static
dev-hugepages.mount static
dev-mqueue.mount static
proc-sys-fs-binfmt_misc.mount static
sys-fs-fuse-connections.mount static
sys-kernel-config.mount static
sys-kernel-debug.mount static
tmp.mount disabled
brandbot.path disabled
systemd-ask-password-console.path static
systemd-ask-password-plymouth.path static
systemd-ask-password-wall.path static
session-1.scope static
arp-ethers.service disabled
auditd.service enabled
[email protected] enabled
<many more entries>
Ovviamente puoi sempre inviare un pipe a grep per vedere solo i servizi abilitati.
$ systemctl list-unit-files |grep enabled
auditd.service enabled
[email protected] enabled
crond.service enabled
dbus-org.fedoraproject.FirewallD1.service enabled
dbus-org.freedesktop.nm-dispatcher.service enabled
firewalld.service enabled
[email protected] enabled
irqbalance.service enabled
kdump.service enabled
lvm2-monitor.service enabled
<many more entries>
Questi file di unità, che si trovano in /lib/systemd/system , sono più o meno equivalenti agli script di inizializzazione legacy che si trovavano in /etc/rc.d/init.d . Infatti, se tu o la tua installazione del software create degli script init, un corrispondente systemd il file unit è mappato per te. Un'ulteriore spiegazione è data da /etc/rc.d/init.d/README :
You are looking for the traditional init scripts in /etc/rc.d/init.d,
and they are gone?
Here's an explanation on what's going on:
You are running a systemd-based OS where traditional init scripts have
been replaced by native systemd services files. Service files provide
very similar functionality to init scripts. To make use of service
files simply invoke "systemctl", which will output a list of all
currently running services (and other units). Use "systemctl
list-unit-files" to get a listing of all known unit files, including
stopped, disabled and masked ones. Use "systemctl start
foobar.service" and "systemctl stop foobar.service" to start or stop a
service, respectively. For further details, please refer to
systemctl(1).
Note that traditional init scripts continue to function on a systemd
system. An init script /etc/rc.d/init.d/foobar is implicitly mapped
into a service unit foobar.service during system initialization.
Thank you!
Further reading:
man:systemctl(1)
man:systemd(1)
http://0pointer.de/blog/projects/systemd-for-admins-3.html
http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities
Come puoi vedere, init.d è stato rimosso a favore di systemd . È qui per restare finché qualcuno non trova qualcosa di meglio. (Spero che qualcuno stia lavorando rapidamente su una sostituzione.)
Elenca unità
L'elenco delle unità attive mostra molte informazioni utili sui servizi caricati e attivi. L'output è troppo dettagliato per essere illustrato qui, ma prova il seguente comando sul tuo sistema per vedere cosa intendo.
$ systemctl list-units I campi di stato sono fantastici da vedere, ma il campo della descrizione è il più utile per me. Fornisce informazioni dettagliate sui tuoi servizi.
Avvia un servizio
Per ottenere un nome di servizio, elenca i file dell'unità e grep per quello che desideri. Quindi usa il systemctl comando per avviare il servizio. Sto usando firewalld come l'esempio.
$ sudo systemctl start firewalld Sorprendentemente, o forse non così sorprendentemente, non c'è risposta dall'avvio, dall'arresto o dal riavvio di un servizio. Per controllare lo stato di un servizio, devi utilizzare il comando status.
Verifica dello stato di un servizio
Per controllare lo stato di un servizio, utilizza systemctl status service-name comando.
$ sudo systemctl status sshd
[sudo] password for khess:
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-04-29 07:44:57 CDT; 2h 17min ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 1055 (sshd)
CGroup: /system.slice/sshd.service
└─1055 /usr/sbin/sshd -D
Apr 29 07:44:57 centos7 systemd[1]: Starting OpenSSH server daemon...
Apr 29 07:44:57 centos7 sshd[1055]: Server listening on 0.0.0.0 port 22.
Apr 29 07:44:57 centos7 sshd[1055]: Server listening on :: port 22.
Apr 29 07:44:57 centos7 systemd[1]: Started OpenSSH server daemon.
Apr 29 07:51:35 centos7 sshd[1396]: Accepted password for khess from 192.168.1.85 port 56769 ssh2 Mi piace lo stato di systemd a causa dei dettagli forniti. Ad esempio, nell'elenco sopra, vedi il percorso completo del file dell'unità, lo stato, il comando di avvio e le ultime modifiche allo stato.
[ Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente. ]
Interrompi un servizio
Interrompere un servizio in esecuzione è facile come avviarne uno.
$ sudo systemctl stop firewalld Ancora una volta, non vedi alcuna risposta dall'emissione di questo comando. Emetti uno stato del servizio per verificare il tuo successo o fallimento.
Riavvio di un servizio
Se vuoi interrompere e avviare un servizio senza emettere due comandi (gli amministratori di sistema sono un sacco di pigri, dopo tutto), esegui un riavvio.
$ sudo systemctl restart firewalld Non viene visualizzata alcuna risposta del sistema.
Riavvio, arresto e arresto del sistema
Queste tre attività sono tipiche che gli amministratori di sistema devono conoscere e ora sono sotto il controllo di systemd .
Riavvia
Esistono diversi modi per riavviare i sistemi, ma il vecchio standby, reboot, è in realtà un collegamento al systemctl comando. Presumo che poiché funziona, colleghi il systemctl comando con l'opzione di riavvio aggiunta come segue:
$ sudo systemctl reboot Lo stesso collegamento vale per l'arresto e per i comandi di spegnimento.
Spegnimento e arresto
Non importa come lo facevi con halt -p o shutdown now o qualsiasi altra cosa, il comando universale ora è:
$ sudo systemctl poweroff Questo comando spegne il sistema.
Imposta i servizi da eseguire all'avvio
Sei abituato a chkconfig comando per consentire l'esecuzione dei servizi all'avvio e in un particolare runlevel. Bene, anche quei giorni sono passati e sono stati usurpati dall'onnipresente systemctl comando.
Abilitazione di un servizio per l'esecuzione all'avvio
Per impostare l'avvio di qualsiasi servizio all'avvio, emettere il comando seguente. Sto usando firewalld come il servizio di esempio.
$ sudo systemctl enable firewalld Disabilitazione dell'esecuzione di un servizio all'avvio
Per impedire l'avvio di qualsiasi servizio all'avvio, emettere:
$ sudo systemctl disable firewalld
Il firewalld il servizio non si avvierà all'avvio.
Concludi
Questo breve ma pratico systemd/systemctl la guida di riferimento dovrebbe alleviare un po' il dolore dovuto alla gestione di systemd . Questa è la teoria, almeno. E, come vedrai spesso nei miei articoli o mi sentirai dire ad alta voce:"Sulla carta funziona tutto". Assicurati di farmi sapere su Twitter cosa ne pensi dei miei articoli e anche di suggerire nuovi argomenti.
[ Corso online gratuito:panoramica tecnica di Red Hat Enterprise Linux. ]