SystemD è uno strumento di gestione del sistema utilizzato per semplificare le attività di amministrazione del sistema e migliorare l'efficienza. Il suo principale vantaggio risiede nella sua capacità di migliorare le prestazioni e la reattività del sistema, oltre a migliorare la sicurezza scansionando automaticamente le vulnerabilità e correggendole.
Inoltre, SystemD può aiutare a organizzare le risorse di sistema in modo più efficace, consentendo ai programmi di essere eseguiti più velocemente e senza intoppi. Nel complesso, se stai cercando uno strumento di gestione del sistema efficace che ti aiuti a ottenere il massimo dal tuo sistema, SystemD è la soluzione ideale. In questo articolo imparerai tutto ciò che devi sapere su SystemD.
A cosa serve SystemD?
SystemD è uno strumento di gestione del sistema che può essere utilizzato per una varietà di attività, dalla gestione delle risorse e dei processi di sistema all'ottimizzazione delle prestazioni del sistema sui sistemi Linux. È ampiamente utilizzato in molti settori diversi, dall'assistenza sanitaria alla produzione, grazie alle sue potenti capacità e alle sue funzionalità avanzate.
Sia che utilizziate server di grandi dimensioni o workstation più piccole, SystemD offre una serie di vantaggi che possono aiutarvi a migliorare l'efficienza e la produttività del sistema. Alcune delle caratteristiche chiave includono la definizione delle priorità dei processi, la registrazione degli eventi di sistema e i controlli dell'allocazione delle risorse di sistema. Quindi, se la tua organizzazione è alla ricerca di uno strumento di gestione del sistema affidabile che possa aiutare a migliorare l'efficienza e le prestazioni in tutti i sistemi, vale sicuramente la pena considerare SystemD.
Perché alle persone non piace SystemD?
Mentre molti utenti ritengono che SystemD sia uno strumento di gestione del sistema inestimabile, ci sono alcuni a cui non piace per una serie di motivi. Alcuni critici sostengono che sia eccessivamente complesso e difficile da usare, soprattutto per coloro che non hanno familiarità con le attività di amministrazione del sistema. Altri affermano che può avere un impatto negativo sulle prestazioni del sistema, portando a tempi di avvio più lenti e a un maggiore utilizzo delle risorse.
Nonostante queste preoccupazioni, tuttavia, SystemD rimane uno degli strumenti di gestione dei sistemi più utilizzati oggi sul mercato e probabilmente continuerà ad esserlo in futuro. Se stai cercando uno strumento di gestione del sistema efficiente che possa aiutare a migliorare la produttività nei sistemi della tua organizzazione, vale sicuramente la pena prendere in considerazione SystemD.
Perché SystemD è controverso?
SystemD è uno strumento di gestione del sistema molto controverso, in gran parte a causa del dibattito in corso sulla sua efficacia e usabilità. Alcuni utenti affermano che può avere un impatto negativo sulle prestazioni del sistema, mentre altri sostengono che offre una serie di importanti vantaggi, come una maggiore sicurezza del sistema e un'allocazione delle risorse di sistema più efficiente.
Ci sono anche preoccupazioni per la complessità e la facilità d'uso di SystemD, con molti utenti che citano la sua curva di apprendimento ripida e l'interfaccia confusa come principali punti critici. Nonostante queste preoccupazioni, tuttavia, SystemD rimane uno degli strumenti di gestione dei sistemi più utilizzati oggi sul mercato e probabilmente continuerà ad esserlo in futuro. Se stai cercando un potente strumento di gestione del sistema che possa aiutare a migliorare le prestazioni e l'efficienza del sistema in tutti i sistemi, allora SystemD potrebbe essere la soluzione ideale per te.
Cos'è SystemD vs init?
SystemD e init sono strumenti di gestione del sistema che vengono spesso confrontati a causa delle loro funzioni simili e delle caratteristiche sovrapposte. Sebbene entrambi gli strumenti di gestione del sistema possano essere utilizzati per una varietà di attività di amministrazione del sistema, come la definizione delle priorità dei processi, la registrazione degli eventi di sistema e i controlli dell'allocazione delle risorse di sistema, esistono alcune differenze fondamentali tra loro.
Mentre init si concentra sui processi di avvio e arresto del sistema, ad esempio, SystemD offre una gamma più ampia di funzionalità di gestione del sistema. Inoltre, molti utenti ritengono che SystemD sia più intuitivo e intuitivo di init, il che lo rende una scelta popolare tra gli amministratori di sistema e i professionisti IT. Nel complesso, se stai cercando una soluzione di gestione del sistema efficace che possa aiutare a migliorare le prestazioni e l'efficienza del sistema in tutti i sistemi, allora SystemD potrebbe essere la scelta ideale per te.
Dovrei usare Grub o SystemD?
Non esiste una risposta definitiva a questa domanda, poiché sia Grub che SystemD hanno i loro vantaggi e svantaggi. Da un lato, Grub è uno strumento di gestione del sistema leggero che offre funzioni semplici e ottimizzate per l'avvio e l'arresto del sistema.
D'altra parte, SystemD offre una gamma più ampia di funzionalità e funzionalità di gestione del sistema, rendendolo uno strumento di gestione del sistema più potente e versatile. In definitiva, se scegli di utilizzare Grub o SystemD dipenderà dalle tue esigenze e preferenze specifiche come amministratore di sistema o professionista IT. Tuttavia, se stai cercando una soluzione di gestione del sistema efficiente che possa aiutare a migliorare le prestazioni e l'efficienza del sistema in tutti i sistemi, probabilmente SystemD è la scelta migliore.
Come usare SystemD
Successivamente, tratteremo un paio di modi in cui puoi utilizzare SystemD su sistemi Linux. Questi sono solo alcuni esempi che puoi provare tu stesso. Ci vuole del tempo per abituarsi alla sintassi, ma una volta che l'hai giù, SystemD diventa uno strumento potente.
SystemD - Init
Questo è il primo processo avviato dal kernel e ottiene il id processo 1 . Gestisce il processo di avvio di attività come la creazione di socket, la configurazione dell'hardware, il montaggio di dischi, ecc.
SystemD funziona con unità di diversi tipi. Accanto al servizio stesso, esiste anche:
- timer
- montare
- rete
- prese
- partizioni
- dispositivi
Inoltre, puoi gestire altri processi con SystemD:
- inizia
- fermati
- riavvia
- uccidi
File-Unit
Esistono diversi percorsi per i file di unità esistenti:
| Percorso | Informazioni |
|---|---|
| /usr/lib/systemd/system | file SystemD predefiniti (non modificare) |
| /etc/systemd/system | Posizione per i file delle unità personalizzate |
| /run/systemd/system | Per i file rilevanti per il runtime |
Informazioni importanti sui percorsi: SystemD preferirà sempre /etc/ a /usr/lib/ . Questo è il motivo per cui inseriamo lì file di unità personalizzate.
Puoi visitare il file unitario di un servizio specifico visitando il percorso o con il comando:
systemctl cat <service>
Code language: Bash (bash)Ad esempio, OpenVPN:
[email protected]:~$ systemctl cat openvpn
# /lib/systemd/system/openvpn.service
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Come possiamo vedere nel file dell'unità, definisci quale percorso viene utilizzato , il file PID e altre opzioni . Di cui parleremo più dettagliatamente di seguito. Possiamo visualizzare tutte le proprietà disponibili con le opzioni che possono essere definite nel file unit per il servizio utilizzando il comando:
systemctl show <service>
Code language: Bash (bash)Ad esempio, anche qui, ci sono le prime righe dell'output di OpenVPN:
[email protected]:~$ systemctl show openvpn
Type=oneshot
Restart=no
NotifyAccess=none
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
TimeoutAbortUSec=1min 30s
TimeoutStartFailureMode=terminate
TimeoutStopFailureMode=terminate
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=n/a
WatchdogTimestampMonotonic=0
RootDirectoryStartOnly=no
RemainAfterExit=yes
GuessMainPID=yes
MainPID=0
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ReloadResult=success
CleanResult=success
UID=[not set]
GID=[not set]
NRestarts=0
OOMPolicy=stop
ExecMainStartTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainStartTimestampMonotonic=9823235
ExecMainExitTimestamp=Sat 2022-09-17 13:00:55 CEST
ExecMainExitTimestampMonotonic=9824084
ExecMainPID=1164
ExecMainCode=1
ExecMainStatus=0v
Code language: Bash (bash)Se ora vogliamo modificare il file unit del servizio, eseguiamo il comando:
systemctl edit – full <service>
Code language: Bash (bash)
Quando eseguiamo il comando senza full opzione, otterremo un file vuoto. Abbiamo la possibilità di creare una copia del file sorgente, che possiamo modificare.
Come esempio di una possibile opzione, immaginiamo di volere che OpenVPN sia sempre in esecuzione. Anche quando il processo viene interrotto o terminato, desideriamo che si riavvii da solo.
Apriamo l'editor e aggiungiamo l'opzione specifica:
# This service is actually a systemd target,
# but we are using a service since targets cannot be reloaded.
[Unit]
Description=OpenVPN service
After=network.target
[Service]
Restart=yes
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
WorkingDirectory=/etc/openvpn
[Install]
WantedBy=multi-user.target
Code language: Bash (bash)Dopodiché, dobbiamo ricaricare il file di configurazione:
systemctl reload <service>
Code language: Bash (bash)E infine, riavvia il servizio:
systemctl restart <service>
Code language: Bash (bash)Con questo comando, SystemD proverà a ricaricare il servizio. Se questo non funziona, riavvierà il servizio:
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)Nei comandi precedenti, abbiamo imparato come controllare i servizi manualmente. SystemD consente inoltre di abilitare o disabilitare permanentemente i servizi in modo che si avviino automaticamente quando necessario o non siano affatto disponibili. La tabella seguente mostrerà i comandi disponibili:
| Comando | Funzione |
|---|---|
| abilita | Attiva un servizio |
| disabilita | Disabilita un servizio |
| è abilitato | Verifica se un servizio è abilitato |
| riattiva | disabilita un servizio e poi lo riattiva |
| maschera | Se vuoi disabilitare completamente un servizio, mascheralo - Fai attenzione |
| smascherare | smaschera un servizio |
Esempio di utilizzo:
systemctl enable <service>
Code language: Bash (bash)Obiettivi
Questi sono stati diversi in cui il sistema può essere avviato.
SystemD aggiunge un nuovo concetto per i noti livelli di esecuzione. Tuttavia, il vecchio principio viene mantenuto. Solo ai livelli di esecuzione vengono assegnati nomi anziché numeri:
| Obiettivo | Effetto |
|---|---|
| halt.target | Spegni il sistema |
| poweroff.target | Spegne fisicamente il sistema (spegnimento) |
| rescue.target | Modalità utente singolo |
| obiettivo.multiutente | Modalità multiutente |
| obiettivo.grafico | Modalità multiutente con interfaccia grafica |
| reboot.target | Riavvia il sistema |
Puoi passare a un'altra destinazione utilizzando il seguente comando:
systemctl isolate example.target
Code language: Bash (bash)Riavvia il sistema:
systemctl reboot
Code language: Bash (bash)Mette il sistema in una sospensione profonda e sospende tutti i processi in esecuzione:
systemctl hybrid-sleep
Code language: Bash (bash)Spegne il sistema con un messaggio broadcast a tutti gli utenti che hanno effettuato l'accesso:
systemctl shutdown
Puoi modificarlo utilizzando i parametri:
systemctl shutdown -r now
Code language: Bash (bash)Ciò riavvierà il sistema (-r) e ignorerà il messaggio di trasmissione e si riavvierà direttamente. Ci sono molti parametri differenti per usare questo comando. Puoi cercarli nella pagina man.
È possibile visualizzare la destinazione corrente in cui si sta avviando il sistema con il seguente comando:
systemctl get-default
Code language: Bash (bash)Inoltre, puoi modificare il target:
systemctl set-default example.target
Code language: Bash (bash)I diversi runlevel possono anche essere visualizzati qui:
ls -la /usr/lib/systemd/system |grep runle*
Code language: Bash (bash)[email protected]:~$ ls -la /usr/lib/systemd/system |grep runle*
lrwxrwxrwx 1 root root 15 Apr 18 22:12 runlevel0.target -> poweroff.target
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel1.target -> rescue.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel1.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel2.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel2.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel3.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel3.target.wants
lrwxrwxrwx 1 root root 17 Apr 18 22:12 runlevel4.target -> multi-user.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel4.target.wants
lrwxrwxrwx 1 root root 16 Apr 18 22:12 runlevel5.target -> graphical.target
drwxr-xr-x 2 root root 4096 Jan 28 2022 runlevel5.target.wants
lrwxrwxrwx 1 root root 13 Apr 18 22:12 runlevel6.target -> reboot.target
-rw-r--r – 1 root root 803 Apr 18 22:12 systemd-update-utmp-runlevel.service
Code language: plaintext (plaintext)Gruppi di controllo
SystemD organizza le attività in gruppi di controllo. Viene utilizzato per il controllo delle risorse in Linux e consente di limitare le risorse disponibili , con priorità , contato, e isolato .
I seguenti comandi sono, quindi, molto utili per analizzare e ottimizzare le prestazioni del sistema:
systemd-analyze
Code language: Bash (bash)Questo comando può essere utilizzato per determinare le prestazioni di avvio.
[email protected]:~$ systemd-analyze
Startup finished in 12.712s (firmware) + 328ms (loader) + 8.240s (kernel) + 6.634s (userspace) = 27.916s
graphical.target reached after 6.631s in userspace
Code language: plaintext (plaintext)Come possiamo vedere, otteniamo una ripartizione dei tempi di avvio di ciascuna attività.
Con il comando aggiuntivo blame otteniamo un elenco molto dettagliato di quanto tempo occorre per avviare il singolo processo:
systemd-analyze blame
Risultato :
[email protected]:~$ systemd-analyze blame
5.573s NetworkManager-wait-online.service
3.244s plymouth-quit-wait.service
2.285s fwupd.service
467ms logrotate.service
392ms lm-sensors.service
385ms accounts-daemon.service
362ms snapd.service
290ms systemd-resolved.service
279ms networkd-dispatcher.service
247ms networking.service
213ms dev-nvme0n1p3.device
182ms apparmor.service
178ms ModemManager.service
174ms systemd-journal-flush.service
168ms udisks2.service
161ms NetworkManager.service
152ms com.system76.Scheduler.service
128ms apport.service
127ms e2scrub_reap.service
116ms rsyslog.service
115ms smartmontools.service
114ms wpa_supplicant.service
105ms [email protected]
100ms gpu-manager.service
....
Code language: plaintext (plaintext)Se vogliamo vedere tutti i gruppi di controllo, possiamo usare:
systemd-cgls
Code language: Bash (bash)o
systemctl status
Code language: Bash (bash)Otterremo un output ad albero con tutte le informazioni necessarie:
[email protected]:~$ systemd-cgls
Control group /:
-.slice
├─user.slice
│ └─user-1000.slice
│ ├─[email protected]
│ │ ├─session.slice
│ │ │ ├─dbus-broker.service
│ │ │ │ ├─3119 /usr/bin/dbus-broker-launch – scope user
│ │ │ │ └─3120 dbus-broker – log 4 – controller 10 – machine-id 04d8535513777afc7bb291c362dd90a7 – max-bytes 100000000000000 – max-fds 25000000000000 – max-matches 50000000>
│ │ │ ├─xdg-document-portal.service
│ │ │ │ ├─3761 /usr/libexec/xdg-document-portal
│ │ │ │ └─3773 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal – /run/user/1000/doc
│ │ │ ├─xdg-desktop-portal.service
│ │ │ │ └─3753 /usr/libexec/xdg-desktop-portal
│ │ │ ├─pipewire-pulse.service
│ │ │ │ └─3112 /usr/bin/pipewire-pulse
│ │ │ ├─wireplumber.service
│ │ │ │ └─3111 /usr/bin/wireplumber
│ │ │ ├─plasma-xdg-desktop-portal-kde.service
│ │ │ │ └─3861 /usr/lib/x86_64-linux-gnu/libexec/xdg-desktop-portal-kde
│ │ │ └─pipewire.service
│ │ │ └─3106 /usr/bin/pipewire
│ │ ├─background.slice
│ │ │ ├─plasma-kactivitymanagerd.service
│ │ │ │ └─3546 /usr/lib/x86_64-linux-gnu/libexec/kactivitymanagerd
│ │ │ ├─plasma-kscreen.service
│ │ │ │ └─3610 /usr/lib/x86_64-linux-gnu/libexec/kf5/kscreen_backend_launcher
│ │ │ ├─plasma-baloorunner.service
│ │ │ │ └─5633 /usr/lib/x86_64-linux-gnu/libexec/baloorunner
│ │ │ ├─plasma-kglobalaccel.service
│ │ │ │ └─3452 /usr/bin/kglobalaccel5
│ │ │ └─tracker-miner-fs-3.service
│ │ │ └─3148 /usr/libexec/tracker-miner-fs-3
│ │ ├─app.slice
│ │ │ ├─app-\\x2fusr\\x2fbin\\x2fkorgac-d27ecb9065d646918a10df1c4fa798fe.scope
│ │ │ │ └─3599 /usr/bin/korgac -session 10dfe2702d000165869202400000083140007_1663442587_18526
│ │ │ ├─gvfs-goa-volume-monitor.service
│ │ │ │ └─3171 /usr/libexec/gvfs-goa-volume-monitor
│ │ │ ├─app-dbus\\x2d:1.2\\x2dorg.gnome.OnlineAccounts.slice
│ │ │ │ └─dbus-:[email protected]
│ │ │ │ └─3174 /usr/libexec/goa-daemon
│ │ │ ├─xdg-permission-store.service
│ │ │ │ └─3765 /usr/libexec/xdg-permission-store
│ │ │ ├─com.system76.SystemUpdater.Local.service
Code language: plaintext (plaintext)
Con il systemd-cgtop comando, otteniamo un elenco di tutti i gruppi di controllo ordinati in base all'utilizzo corrente delle risorse:
systemd-cgtop
Code language: Bash (bash)Ora, perché questo è importante per noi? Ora possiamo analizzare l'utilizzo delle risorse dei singoli processi e, se necessario, regolare la priorità del processo o modificare il limite delle risorse.
La pagina man ci offre molte possibilità per gestirlo:
man systemd.resource-control
Code language: Bash (bash)Ad esempio, se vogliamo impostare il limite di memoria di un servizio specifico, possiamo utilizzare:
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Registrazione - JournalD
JournalD registra tutti gli eventi nella RAM del sistema. Questo verrà cancellato con un riavvio del sistema.
Puoi usare JournalD con il seguente comando:
journalctl
Code language: Bash (bash)Possiamo perfezionare ulteriormente l'output aggiungendo filtri, ad esempio, con un tempo specifico:
journalctl – since yesterday
Code language: Bash (bash)Possiamo perfezionarlo ancora di più specificando un periodo di tempo esatto da a:
journalctl – since "date" – until "date"
Code language: Bash (bash)Un altro modo per filtrare è seguire servizi specifici:
journalctl -u example
Code language: Bash (bash)Possiamo anche seguire un servizio specifico e filtrare solo per questo:
journalctl -fu example
Code language: Bash (bash)Potremmo anche filtrare solo per gli eventi del kernel:
journalctl -k
Code language: Bash (bash)Riepilogo
SystemD è un potente successore del classico demone init di System V e fornisce all'amministratore molte informazioni e strumenti utili che velocizzano il lavoro e il flusso di lavoro quotidiani. Se vuoi saperne di più su altri argomenti approfonditi su Linux, assicurati di visitare il blog di Max Wilke.
- SystemD è uno strumento di gestione del sistema che può essere utilizzato per attività come la gestione delle risorse di sistema e processi , ottimizzazione delle prestazioni del sistema e migliorare la sicurezza .
- SystemD offre una serie di vantaggi che possono aiutare le organizzazioni a migliorare l'efficienza e la produttività , inclusa la assegnazione delle priorità dei processi , registrazione eventi di sistema e controlli di allocazione delle risorse .
- Sebbene SystemD sia ampiamente utilizzato da molti settori diversi grazie alle sue potenti capacità, ad alcuni utenti non piace perché è complesso o difficile da usare . Inoltre, alcuni critici sostengono che può avere un impatto negativo sulle prestazioni del sistema .
- Nonostante queste preoccupazioni, SystemD rimane uno degli strumenti di gestione dei sistemi più popolari oggi sul mercato.