SystemD je nástroj pro správu systému, který se používá k zefektivnění úloh správy systému a zvýšení efektivity. Jeho primární výhoda spočívá v jeho schopnosti zlepšit výkon a odezvu systému a také zlepšit zabezpečení automatickým skenováním zranitelností a jejich opravami.
Kromě toho může SystemD pomoci efektivněji organizovat systémové prostředky a umožnit programům běžet rychleji a plynuleji. Celkově vzato, pokud hledáte efektivní nástroj pro správu systému, který vám pomůže vytěžit ze systému maximum, pak je SystemD ideálním řešením. V tomto článku se dozvíte vše, co potřebujete vědět o SystemD.
K čemu se SystemD používá?
SystemD je nástroj pro správu systému, který lze použít pro různé úkoly, od správy systémových prostředků a procesů až po optimalizaci výkonu systému na systémech Linux. Je široce používán v mnoha různých odvětvích, od zdravotnictví po výrobu, díky svým výkonným schopnostem a pokročilým funkcím.
Ať už provozujete velké servery nebo menší pracovní stanice, SystemD nabízí řadu výhod, které vám mohou pomoci zlepšit efektivitu a produktivitu systému. Některé z klíčových funkcí zahrnují prioritizaci procesů, protokolování systémových událostí a řízení alokace systémových prostředků. Pokud tedy vaše organizace hledá spolehlivý nástroj pro správu systému, který může pomoci zvýšit efektivitu a výkon napříč všemi systémy, pak SystemD rozhodně stojí za zvážení.
Proč lidé nemají rádi SystemD?
Zatímco mnoho uživatelů považuje SystemD za neocenitelný nástroj pro správu systému, jsou někteří, kteří jej z různých důvodů nemají rádi. Někteří kritici tvrdí, že je příliš složitý a obtížně použitelný, zejména pro ty, kteří nejsou obeznámeni s úkoly správy systému. Jiní tvrdí, že to může negativně ovlivnit výkon systému, což vede k pomalejšímu spouštění a zvýšenému využití zdrojů.
Navzdory těmto obavám však SystemD zůstává jedním z nejrozšířenějších nástrojů pro správu systému na současném trhu a pravděpodobně tomu tak bude i v budoucnu. Pokud hledáte účinný nástroj pro správu systému, který může pomoci zvýšit produktivitu napříč systémy vaší organizace, pak SystemD rozhodně stojí za zvážení.
Proč je SystemD kontroverzní?
SystemD je vysoce kontroverzní nástroj pro správu systému, z velké části kvůli probíhající debatě o jeho účinnosti a použitelnosti. Někteří uživatelé tvrdí, že to může negativně ovlivnit výkon systému, zatímco jiní tvrdí, že to nabízí řadu důležitých výhod, jako je lepší zabezpečení systému a efektivnější alokace systémových zdrojů.
Existují také obavy ohledně složitosti a uživatelské přívětivosti SystemD, přičemž mnoho uživatelů uvádí jako hlavní body kritiky jeho strmou křivku učení a matoucí rozhraní. Navzdory těmto obavám však SystemD zůstává jedním z nejpoužívanějších nástrojů pro správu systému na současném trhu a pravděpodobně tomu tak bude i v budoucnu. Pokud hledáte výkonný nástroj pro správu systému, který může pomoci zlepšit výkon a efektivitu systému napříč všemi systémy, pak pro vás může být SystemD ideálním řešením.
Co je SystemD vs init?
SystemD a init jsou nástroje pro správu systému, které jsou často srovnávány kvůli jejich podobným funkcím a překrývajícím se funkcím. Zatímco oba nástroje pro správu systému lze použít pro různé úkoly správy systému, jako je stanovení priorit procesů, protokolování systémových událostí a řízení alokace systémových zdrojů, existují mezi nimi některé klíčové rozdíly.
Zatímco init se zaměřuje například na procesy spouštění a vypínání systému, SystemD nabízí širší škálu možností správy systému. Mnoho uživatelů navíc považuje SystemD za uživatelsky přívětivější a intuitivnější než init, což z něj činí oblíbenou volbu mezi správci systému a IT profesionály. Celkově vzato, pokud hledáte efektivní řešení správy systému, které může pomoci zlepšit výkon a efektivitu systému napříč všemi systémy, pak pro vás může být SystemD ideální volbou.
Mám používat Grub nebo SystemD?
Na tuto otázku neexistuje žádná definitivní odpověď, protože Grub i SystemD mají své výhody a nevýhody. Na jedné straně je Grub odlehčený nástroj pro správu systému, který nabízí jednoduché a efektivní funkce pro spouštění a vypínání systému.
Na druhou stranu SystemD nabízí širší škálu možností a funkcí správy systému, což z něj dělá výkonnější a všestrannější nástroj pro správu systému. To, zda se rozhodnete používat Grub nebo SystemD, bude nakonec záviset na vašich konkrétních potřebách a preferencích jako správce systému nebo IT profesionála. Pokud však hledáte efektivní řešení správy systému, které může pomoci zlepšit výkon a efektivitu systému ve všech systémech, pak je SystemD pravděpodobně lepší volbou.
Jak používat SystemD
Dále probereme několik způsobů, jak můžete použít SystemD v systémech Linux. Toto je jen několik příkladů, které si můžete sami vyzkoušet. Chvíli trvá, než si na syntaxi zvyknete, ale jakmile ji vypnete, SystemD se stane mocným nástrojem.
SystemD – Init
Toto je první proces spuštěný jádrem a získává ID procesu 1 . Řídí spouštěcí proces, úlohy, jako je vytváření soketů, nastavení hardwaru, montáž disků atd.
SystemD pracuje s jednotkami různých typů. Vedle samotné služby existuje také:
- časovač
- připojit
- síť
- zásuvky
- oddíly
- zařízení
Kromě toho můžete pomocí SystemD spravovat další procesy:
- začít
- přestaňte
- restartovat
- zabít
Soubory jednotek
Existují různé cesty pro existující soubory jednotek:
| Cesta | Informace |
|---|---|
| /usr/lib/systemd/system | předdefinované soubory SystemD (neupravovat) |
| /etc/systemd/system | Umístění pro soubory vlastních jednotek |
| /run/systemd/system | Pro soubory relevantní za běhu |
Důležité informace o cestách: SystemD bude vždy preferovat /etc/ před /usr/lib/ . To je důvod, proč tam umísťujeme vlastní soubory jednotek.
Soubor jednotky konkrétní služby můžete navštívit na cestě nebo pomocí příkazu:
systemctl cat <service>
Code language: Bash (bash)Například 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)Jak vidíme v souboru jednotky, definujte, která cesta se použije , soubor PID a další možnosti . O čemž se budeme podrobněji bavit níže. Můžeme zobrazit všechny dostupné vlastnosti s možnostmi, které lze definovat v souboru jednotek pro službu pomocí příkazu:
systemctl show <service>
Code language: Bash (bash)Zde jsou například opět první řádky výstupu 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)Pokud nyní chceme upravit soubor jednotek služby, spustíme příkaz:
systemctl edit – full <service>
Code language: Bash (bash)
Když spustíme příkaz bez full možnost, získáme prázdný soubor. Máme možnost vytvořit kopii zdrojového souboru, kterou můžeme upravit.
Jako příklad možné možnosti si představme, že chceme, aby OpenVPN vždy běžela. I když se proces zastavuje nebo zastavuje, chceme, aby se restartoval sám.
Otevřeme editor a přidáme konkrétní možnost:
# 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)Poté musíme znovu načíst konfigurační soubor:
systemctl reload <service>
Code language: Bash (bash)A nakonec restartujte službu:
systemctl restart <service>
Code language: Bash (bash)Pomocí tohoto příkazu se SystemD pokusí znovu načíst službu. Pokud to nepomůže, restartuje se služba:
systemctl reload-or-restart <service>
Code language: HTML, XML (xml)Ve výše uvedených příkazech jsme se naučili ovládat služby ručně. SystemD také umožňuje trvale povolit nebo zakázat služby tak, aby se v případě potřeby spouštěly automaticky nebo nebyly vůbec dostupné. V následující tabulce jsou uvedeny dostupné příkazy:
| Příkaz | Funkce |
|---|---|
| povolit | Aktivuje službu |
| zakázat | Zakáže službu |
| je-povolit | Zkontrolujte, zda je služba povolena |
| znovu povolit | zakáže službu a poté ji znovu povolí |
| maska | Pokud chcete službu úplně zakázat, zamaskujte ho - Buďte opatrní |
| odmaskování | odmaskuje službu |
Příklad použití:
systemctl enable <service>
Code language: Bash (bash)Cíle
Toto jsou různé stavy, ve kterých může systém zavést.
SystemD přidává nový koncept pro známé úrovně běhu. Starší princip je však zachován. Pouze úrovně běhu mají místo čísel názvy:
| Cíl | Efekt |
|---|---|
| halt.target | Vypněte systém |
| poweroff.target | Fyzicky vypne systém (vypne napájení) |
| rescue.target | Režim jednoho uživatele |
| multi-user.target | Režim více uživatelů |
| graphical.target | Režim pro více uživatelů s grafickým rozhraním |
| reboot.target | Restartuje systém |
Na jiný cíl se můžete přepnout pomocí následujícího příkazu:
systemctl isolate example.target
Code language: Bash (bash)Restartujte systém:
systemctl reboot
Code language: Bash (bash)Uvede systém do hlubokého spánku a pozastaví všechny běžící procesy:
systemctl hybrid-sleep
Code language: Bash (bash)Vypne systém vysílanou zprávou všem přihlášeným uživatelům:
systemctl shutdown
Toto můžete upravit pomocí parametrů:
systemctl shutdown -r now
Code language: Bash (bash)Tím by se restartoval systém (-r) a obešel by se vysílaná zpráva a restartoval by se přímo. Pro použití tohoto příkazu existuje mnoho různých parametrů. Můžete si je vyhledat na manuálové stránce.
Aktuální cíl, ze kterého systém zavádí, můžete zobrazit pomocí následujícího příkazu:
systemctl get-default
Code language: Bash (bash)Kromě toho můžete upravit cíl:
systemctl set-default example.target
Code language: Bash (bash)Různé úrovně běhu lze také zobrazit zde:
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)Kontrolní skupiny
SystemD organizuje úkoly v kontrolních skupinách. To se používá pro řízení zdrojů v Linuxu, což umožňuje omezit dostupné zdroje , upřednostňováno , počítané a izolované .
Následující příkazy jsou proto velmi užitečné pro analýzu a optimalizaci výkonu systému:
systemd-analyze
Code language: Bash (bash)Tento příkaz lze použít k určení výkonu spouštění.
[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)Jak vidíme, dostáváme rozpis časování, jak dlouho trvá spuštění každého úkolu.
Pomocí dodatečného příkazu blame dostaneme velmi podrobný seznam toho, jak dlouho musí být který proces spuštěn:
systemd-analyze blame
Výstup :
[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)Pokud chceme vidět všechny kontrolní skupiny, můžeme použít:
systemd-cgls
Code language: Bash (bash)nebo
systemctl status
Code language: Bash (bash)Získáme stromový výstup se všemi potřebnými informacemi:
[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)
Pomocí systemd-cgtop dostaneme seznam všech kontrolních skupin seřazených podle aktuálního využití zdrojů:
systemd-cgtop
Code language: Bash (bash)Proč je to pro nás důležité? Nyní můžeme analyzovat využití zdrojů jednotlivých procesů a v případě potřeby upravit prioritu procesu nebo změnit limit zdrojů.
Manová stránka nám poskytuje mnoho možností, jak to spravovat:
man systemd.resource-control
Code language: Bash (bash)Například – pokud chceme nastavit limit paměti konkrétní služby, můžeme použít:
systemctl set property example.service MemoryLimit=1G
Code language: Bash (bash)Logging – JournalD
JournalD zaznamenává všechny události do paměti RAM systému. Toto bude vymazáno restartováním systému.
JournalD můžete použít s následujícím příkazem:
journalctl
Code language: Bash (bash)Výstup můžeme dále zpřesnit přidáním filtrů, například s konkrétním časem:
journalctl – since yesterday
Code language: Bash (bash)Můžeme jej ještě více upřesnit zadáním přesného časového období od do:
journalctl – since "date" – until "date"
Code language: Bash (bash)Dalším způsobem filtrování je sledování konkrétních služeb:
journalctl -u example
Code language: Bash (bash)Můžeme také sledovat konkrétní službu a filtrovat pouze pro tuto:
journalctl -fu example
Code language: Bash (bash)Mohli bychom také filtrovat pouze pro události jádra:
journalctl -k
Code language: Bash (bash)Přehled
SystemD je silným nástupcem klasického iniciačního démona System V a poskytuje správci spoustu užitečných informací a nástrojů, které urychlují každodenní práci a pracovní toky. Pokud se chcete dozvědět více o dalších hloubkových tématech Linuxu, navštivte blog Maxe Wilkeho.
- SystemD je nástroj pro správu systému, který lze použít pro úlohy, jako je správa systémových prostředků a procesy , optimalizace výkonu systému a zlepšení zabezpečení .
- SystemD nabízí řadu výhod, které mohou organizacím pomoci zvýšit efektivitu a produktivitu včetně stanovení priority procesů , protokolování systémových událostí a ovládací prvky přidělování zdrojů .
- I když je SystemD díky svým výkonným schopnostem široce používán v mnoha různých odvětvích, někteří uživatelé jej nemají rádi, protože je složitý nebo obtížně použitelný . Někteří kritici navíc tvrdí, že může negativně ovlivnit výkon systému .
- Navzdory těmto obavám zůstává SystemD jedním z nejpopulárnějších nástrojů pro správu systémů na současném trhu.