A Linux rendszerbetöltési folyamata
Mivel a systemd a Linux rendszerindításának egyik legfontosabb lépcsőfoka, érdemes megismernünk a rendszerindítás folyamat főbb szakaszait:
- BIOS, UEFI: Mind a BIOS (Basic Input/Output System), mind az UEFI (Unified Extensible Firmware Interface) az alaplapon található olyan szoftverkomponens, mely először kapja meg a vezérlést, miután az alaplap megkapja a tápegységtől a működéséhez szükséges feszültségeket. Inicializálják és leellenőrzik a hardverkomponenseket, betölti a CMOS-ból az alapvető hardverkonfigurációs adatokat, majd átadja a vezérlést a rendszerbetöltőnek.
- Rendszerbetöltő: Miután a BIOS a CMOS konfigurációs adataira támaszkodva meghatározza, hogy honnan kell betölteni az operációs rendszert, megkeresi ezen az eszközön a rendszerbetöltő szoftverkomponenst. (A régi MBR alapú rendszerekben ez például az aktív partíció első 512 byte-os szektorban volt megtalálható.) Ez a rendszerbetöltő fogja elindítani magának az operációs rendszernek a betöltését. (Ebben a szakaszban betöltésre kerülhet egy bootloader szoftverkomponens is (pl. a grub), amely megjelenít egy olyan boot menüt, amelyen keresztül meghatározhatjuk, hogy melyik operációs rendszer és milyen paraméterekkel töltődjön be.)
- Kernel, initramfs, initrd: A rendszerbetöltő betölti a operációs rendszer kernelét. Az initramfs (initial RAM file system) fájlrendszer (korábban ez az initrd (initial RAM disk) volt) ilyenkor kerül a memóriába, és használatával a rendszer a kezdeti fázisban hozzáférhet azokhoz az eszközillesztőkhöz, modulokhoz és szükséges erőforrásokhoz, amelyekre a rendszerindítás során szükség van.
- Root fájlrendszer betöltése: Az initramfs-ben található init program csatolja fel a root fájlrendszert, hibaellenőrzést végez rajta. Ha minden rendben talál, akkor az initramfs törlődik, és elindul a root fájlrendszeren található init program. Ez a program az ebben az írásban tárgyalt systemd.
- Systemd: A systemd végzi az operációs rendszer tényleges indítását, meghatározza, hogy mely folyamatok kerüljenek elindításra.
Systemd és systemctl
A systemd mint láthattuk a Linux rendszerek elterjedt inicializációs rendszere és szolgáltatás menedzsere, amelyet a RedHat fejlesztett ki, de mára számos disztribúció használja. Feladata, hogy a kernel betöltése után, illetve később, a rendszer futása közben betöltse a szükséges erőforrásokat, elindítsa a szolgáltatásokat. Ezeket együttesen unit-oknak vagy egység-eknek nevezzük. Egy egység lehet például egy szolgáltatás, folyamat, erőforrás vagy akár hardverkomponens. Ebben a dokumentációban az egységeket szolgáltatásként fogjuk nevezni, hiszen végeredményben mindegyik egy-egy szolgáltatást nyújt a rendszerben. A systemd a korábbi SysV rendszerkezelő init rendszert váltotta le 2018-as megjelenésével, és rohamosan terjed el az egyes disztribúciókban. (Bár meg kell jegyezni, hogy elfogadottsága nem egyöntetű, mivel ma már nem csak az init rendszer kezelését látja el, hanem akár a naplózást, a felhasználók vagy a hálózatok kezelését is magába foglalja, és ezt sokan nagyon rossz iránynak tekintik. Még weboldal is született ellene… ) Bárhogy is legyen, a systemd egyre inkább jelen van, így meg kell ismernünk. Főbb előnyei:
- Lehetővé teszi a szolgáltatások párhuzamos betöltését (aszinkron módban kezelését), felgyorsítva ezzel a rendszerindítást. (Az init még csak egymás után indította ezeket.)
- Az szolgáltatás leíró fájlok (vagy egységfájlok) bevezetésével megkönnyítette a szolgáltatások betöltését, indítását, leállítását, konfigurálását és a hibakeresést. (Egy egységfájl egy szolgáltatásról tartalmaz részletes információkat.)
- Egységesen kezeli a naplófájlokat, egy központi helyre irányítva a naplóbejegyzéseket.
- A systemd-networkd komponens segítségével egységes és könnyebb hálózatkezelést biztosít.
- Az olyan rendszereseményeket, mint például hiba esetén a folyamatok újraindítása, hatékonyabban végzi el.
- Támogatja a régi init rendszer szkriptjeinek futtatását.
Az szolgáltatások típusuk szerint kategorizálva vannak. Az egységfájlok végén az utótag neve utal a típusukra. Mi legtöbbször a szolgáltatásokat megvalósító egységekkel foglalkozunk, ezeket a .service utótag azonosítja. (Legtöbbször ez az utótag el is hagyható, mert a systemd felismeri, hogy milyen egységről van szó.) A gyakrabban használt típusok még a mount (csatolás, .mount), a socket (.socket), az device (eszköz, .device) és a timer (időzítő, .timer).
A systemctl egy olyan parancssori eszköz, amely segítségével a systemd szolgáltatásokat tudjuk kezelni és felügyelni. Nézzük meg ennek az eszköznek a leggyakrabban használt lehetőségeit:
Szolgáltatások indítása és leállítása
Szolgáltatásokat indítani és leállítani a start és stop parancsokkal tudunk:
systemctl start application.service systemctl start application
systemctl stop application.service
Ennek a két parancsnak a hatását egyben, a restart parancs kiadásával is elérhetjük:
systemctl restart application.service
Nem csak szolgáltatás típusú egységek indíthatók el. Ha például egy .mount típusú egységet indítunk, annak eredményeként egy eszköz (pl. /dev/sdb1) felcsatlakozik a fájlrendszerbe (pl. a /mnt/data könyvtárba). Mi a következőkben többnyire szolgáltatás típusú egységekkel foglalkozunk.
Sokszor áll elő az a helyzet, hogy a szolgáltatásnak a konfigurációját módosítottuk, de magát a szolgáltatást nem akarjuk leállítani és újraindítani, hogy az új konfigurációt használja, hanem csak a konfigurációt akarjuk betölteni a szolgáltatás futásának megszakítása nélkül. Ilyenkor a reload parancsot használjuk:
systemctl reload application.service
Nem minden szolgáltatás támogatja a konfiguráció futás közbeni betöltését. Ilyenkor a reload-or-restart paranccsal a systemctl dönti el, hogy melyik módot alkalmazza:
systemctl reload-or-restart application.service
Szolgáltatások engedélyezése és letiltása
Amennyiben szeretnénk engedélyezni, hogy egy szolgáltatás rendszerindításkor automatikusan betöltődjön, az enable parancsot használjuk. Mint korábban olvashattuk, ezek kezelését az egységfájlok írják le, melyek általában a /lib/systemd/system vagy a /etc/systemd/system könyvtárban vannak elhelyezve. Az enable parancs ezekhez készít egy-egy szimbolikus linket a /etc/systemd/system könyvtárba. Rendszerindításkor itt keresi a systemd az automatikusan betöltendő szolgáltatásokat. (Az enable tehát nem indítja el azonnal a szolgáltatást, csak engedélyezi, hogy a rendszer újraindításakor betöltődjön.)
systemctl enable application.service
Ha az ellenkezőjét szeretnénk, tehát a rendszerrel együtt ne töltődjön be, a disable parancsot használjuk. (Ilyenkor az előzőekben létrehozott link törlődik.)
systemctl disable application.service
Szolgáltatások állapotának lekérdezése
A status paranccsal egy szolgáltatás státusza kérdezhető le:
systemctl status application.service
Kérdezzük le például a Docker állapotát:
systemctl status docker ● docker.service - Docker Application Container Engine Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/docker.service.d └─service.conf Active: active (running) since Mon 2023-06-05 09:09:54 UTC; 3 days ago TriggeredBy: ● docker.socket Docs: https://docs.docker.com">https://docs.docker.com Main PID: 2273 (dockerd) Tasks: 11 Memory: 130.8M CGroup: /system.slice/docker.service └─2273 /usr/bin/dockerd --iptables=false
Jól látható, hogy számos információ jelenik meg a képernyőn. Ha csak arra vagyunk kíváncsiak, hogy a szolgáltatás fut-e, az is-active parancsot használjuk:
systemctl is-active application.service
Ha pedig arra vagyunk kíváncsiak, hogy a szolgáltatás automatikus indítása engedélyezve van-e, az is-enabled parancsot válasszuk:
systemctl is-enabled application.service
Azt, hogy egy szolgáltatás valamilyen hiba miatt nem tud elindulni, az is-failed paranccsal vizsgálható:
systemctl is-failed application.service
Rendszerállapot lekérdezése
A systemd által kezelt aktív (vagyis futó) szolgáltatások a list-units paranccsal kérdezhetők le. (Fontos, hogy a parancs ilyen formában csak az aktív állapotú (tehát futó) szolgáltatás típusú egységeket jeleníti meg.)
systemctl list-units
A parancs kimenet3ében az információk 5 oszlopban jelennek meg:
- UNIT: A szolgáltatás neve
- LOAD: Ha be tudta olvasni a szolgáltatás konfigurációs állapotát, akkor loaded, ha nem, akkor not-found
- ACTIVE: Ha a szolgáltatás fut, akkor active, ha nem fut, akkor inactive
- SUB: Az aktuális állapotot írja le (pl. running vagy exited)
- DESCRIPTION: A szolgáltatás leírása
A fenti paranccsal egyenértékű, ha argumentum nélkül hívjuk meg a systemctl-t.
Ha valamennyi szolgáltatást látni akarunk (a futókat és nem futókat is), használjuk a –all kapcsolót:
systemctl list-units --all
Ha valamelyik szolgáltatás mellett a LOAD oszlopban a loaded, míg az ACTIVE oszlopban a failed jelenik meg, akkor az azt jelenti hogy a systemd megpróbálta betölteni, tehát megtalálta az szolgáltatáshoz tartozó egységfájlt, de a betöltés közben valami hiba lépett fel, így az nem lett aktív.
Ha csak bizonyos állapotú szolgáltatásokat akarunk kilistázni, akkor használjuk a –state kapcsolót. Listázzuk ki például az inaktívakat:
systemctl list-units --all --state=inactive
Amennyiben csak egy bizonyos típusú egységekről akarunk listát, akkor a –type kapcsoló a megoldás. Listázzuk ki a mount típusú egységeket:
systemctl list-units --type=mount
Az egységfájlok kilistázása
A list-units parancs csak azokat az egységeket jeleníti meg, melyeknek az egységfájljait a systemd megpróbálta betölteni. De van számos olyan egység is, amelyet meg sem próbál, ilyenek például a letiltottak (disabled). A list-units-files parancs viszont valamennyi egységet kilistázza:
systemctl list-unit-files UNIT FILE STATE VENDOR PRESET proc-sys-fs-binfmt_misc.automount static enabled -.mount generated enabled boot.mount generated enabled dev-hugepages.mount static enabled dev-mqueue.mount static enabled proc-sys-fs-binfmt_misc.mount disabled enabled snap-core18-2745.mount enabled enabled snap-core18-2751.mount enabled enabled snap-core20-1879.mount enabled enabled
A parancs kimenet3ében a szolgáltatások mellett 2 állapot jelenik meg. A STATE oszlopban a következőket láthatjuk: enabled (rendszerinduláskor betöltődik), disabled (rendszerinduláskor nem töltődik be), static (nem a systemd kezeli), masked (le van letiltva, erősebb, mint a disabled). Amennyiben itt generated állapotot látunk, az azt jelenti, hogy a konfigurációt a rendszer hozta létre, és a felhasználó által közvetlenül nem módosítható. A VENDOR PRESET oszlop a gyártói beállítást tartalmazza, és azt jelzi, hogy az egységfájl engedélyezve (enabled), vagy letiltva (disabled) van a gyártói alapbeállítás szerint.
Szolgáltatásmenedzsment
Egy egységfájl tartalma a cat paranccsal jeleníthető meg:
systemctl cat apache2.service
A képernyőn a következő jelenik meg: (Persze a használt rendszertől függően.)
#/lib/systemd/system/apache2.service [Unit] Description=The Apache HTTP Server After=network.target remote-fs.target nss-lookup.target Documentation=https://httpd.apache.org/docs/2.4/ [Service] Type=forking Environment=APACHE_STARTED_BY_SYSTEMD=true ExecStart=/usr/sbin/apachectl start ExecStop=/usr/sbin/apachectl stop ExecReload=/usr/sbin/apachectl graceful Restart=on-abort [Install] WantedBy=multi-user.target
A Unit szakasz a szolgáltatás leírása (Description) és a dokumentációjának forrása (Documentation) mellett az After kulcsszó után tartalmazza a függőséget, azaz a betöltődéséhez milyen más szolgáltatásoknak kell betöltve lenniük.
A Service szakaszban adjuk meg, hogyan kell a szolgáltatást kezelni (start, stop, reload). A Type=forking azt jelenti, hogy a szolgáltatás egy ős folyamatként indul el, mely egy vagy több gyermek folyamatot indít, melyek párhuzamosan kiszolgálják a kéréseket, miközben az ős folyamat leáll. (Ez a forking mechanizmus.) Ha egy ilyen gyermekfolyamat hiba miatt leállna, a systemd újraindítja (Restart=on-abort)
Az Install szekcióban a WantedBy=multi-user.target sor írja elő, hogy az Apache a többfelhasználós környezetben induljon el. (A target-ek (célok) olyan pontok egy Linux rendszer elindulása közben, melyeket elérve meghatározott szolgáltatásoknak kell betöltve lennie.)
Függőségek megjelenítése
Az egyes szolgáltatások működése egymástól függ, ezek a függőségek jeleníthetők meg a list-dependencies paranccsal:
systemctl list-dependencies apache2
Ehhez hasonló (csak sokkal bővebb) listát kapunk:
apache2.service ● ├─system.slice ● └─sysinit.target ● ├─apparmor.service ● ├─blk-availability.service ● ├─dev-hugepages.mount ● ├─dev-mqueue.mount ● ├─finalrd.service ● ├─keyboard-setup.service ● ├─kmod-static-nodes.service
A lista egy hierarchikus rendszerben mutatja a szolgáltatások egymástól való függését. A lista minden eleme előtt egy színes kör (ebben a dokumentációban nem látszódnak a különböző színek…) mutatja az adott szolgáltatás elérhetőségét, állapotát:
- Zöld kör: A szolgáltatás aktív és fut.
- Fehér kör: A szolgáltatás inaktív, nem fut, de telepítve van a rendszeren és rendelkezésre áll.
- Sárga kör: A szolgáltatás megszakadt vagy függőségi hibát tapasztalt.
- Piros kör: A szolgáltatás hibát jelentett vagy nem sikerült elindítani.
- Szürke kör: A szolgáltatás vagy függőségei nincsenek telepítve a rendszeren.
Fontos megjegyezni, hogy a parancs ilyen formában csak az aktív szolgáltatások függőségeit mutatja meg, az inaktív vagy a megszakadt futású szolgáltatásokét nem. Ha ezekre is kíváncsiak vagyunk, használjuk a –all kapcsolót.
A függőségi láncot visszafelé is megjeleníthetjük a –reverse kapcsolóval. Ez apache2-re alkalmazva a parancsot így:
systemctl list-dependencies apache2 --reverse apache2.service ● └─multi-user.target ● └─graphical.target
A parancsot kimenet3ét így értelmezhetjük: Az apache2 név az apache2.service szolgáltatáshozhoz van rendelve. Ez a szolgáltatás a multi-user.target és a graphical.target célokhoz van kapcsolva. Az apache2.services akkor fut, ha a multi-user.target már fut, ez pedig akkor fut, ha a graphical.target fut már. (Vagyis először a grafikus rendszer indul el, utána a többfelhasználós rendszer, és utána futhat az apache.)
A –before és az –after kapcsolók használatával az adott szolgáltatás előtt futtatandó, illetve az utána futtatandó szolgáltatások függőségi listája jeleníthető meg.
A szolgáltatások tulajdonságainak megjelenítése
Egy szolgáltatás tulajdonságairól a show paranccsal tudunk részletes listát megjeleníteni. (A következő parancs az én rendszeremen 241 sornyi információt jelenít meg az apache2-ről.)
systemctl show apache2.service
Ha nem a teljes listára vagyunk kíváncsiak, hanem csak bizonyos tulajdonságra, akkor használjuk a -p kapcsolót. Kérdezzük le például az apache2 indításának az időpontját:
systemctl show apache2.service -p ExecMainStartTimestamp
ExecMainStartTimestamp=Mon 2023-06-05 09:09:53 UTC
Szolgáltatás kikapcsolása (maszkolás, masking) és visszakapcsolása (feloldás, unmasking)
Amennyiben egy szolgáltatást maszkolunk a mask paranccsal, az sem automatikusan, sem manuálisan nem lesz elindítható. Ezt az állapotot feloldani az unmasking paranccsal lehet:
systemctl mask apache2.service systemctl unmask apache2.service
Nagyon hasznos ez a funkció akkor, ha egy szolgáltatás konfliktusba kerülne egy másikkal, akkor így tudjuk elérni, hogy véletlenül se lehessen elindítani.
Az erőforrásfájlok szerkesztése
Mint korábban láthattuk, az egyes egységeket egységfájlokkal írjuk le. Ezek vagy a /lib/systemd/system könyvtárban (itt általában a rendszerhez tartozó alapértelmezett egységfájlokfájlok), vagy a /etc/systemd/system könyvtárban (itt általában a felhasználó által létrehozott vagy módosított egységfájlok) találhatók. Ezek bármilyen szerkesztővel szerkeszthetők, de a systemctl is lehetőséget ad rá az edit paranccsal:
systemctl edit --full apache2.service
A –full kapcsoló használata azt eredményezi, hogy az eredeti egységfájl kerül szerkesztésre. Ez azt a veszélyt hordozza magával, hogy bármilyen hiba (akár véletlen szerkesztés) a szolgáltatás hibás indulásához vezet. Ezért bevezettek egy másik módot is, amikor a –full kapcsoló nélkül adjuk ki a parancsot:
systemctl edit apache2.service
Ilyenkor egy üres fájlt szerkeszthetünk, melynek tartalma majd kiegészíti az eredetit. A működése a következő: A /etc/systemd/system könyvtárban létrejön egy olyan könyvtár, melynek neve a egység nevével megegyezik .d-vel kiegészítve, (Pl. /etc/systemd/system/apache2.service.d) és ebben jön létre egy override.conf állomány. Ez fogja tartalmazni mindazt a módosítást, amit beírunk. Amikor a szolgáltatás indul, ezt és az eredeti egységfájlt is használja úgy, hogy az override.conf az elsődleges, vagyis az ebben megtalálható beállítások hajtódnak végre először. Így elkerülhetjük, hogy az eredetit kelljen módosítani. Ha vissza akarjuk vonni a módosításokat, törölni kell csak a .d a könyvtárat.
Nézzünk erre egy példát! Készítsünk el egy egyszerű egységfájlt, amely egy üzenetet (Hello, World!) küld az echo paranccsal:
nano /etc/systemd/system/print-message.service [Unit] Description=Print Message [Service] Type=oneshot ExecStart=/bin/bash -c 'echo "Hello, World!"' [Install] WantedBy=multi-user.target
Magyarázatra egyedül a Type=oneshot sor szorul, amellyel azt adjuk meg, hogy a systemd egyszer futtassa le a szolgáltatást, utána zárja be, ne fusson a háttérben. Ellenőrizzük le, hogy elérhető-e a systemd számára:
systemctl list-unit-files | grep print-message print-message.service disabled enabled
Frissítsük a systemd-t, majd indítsuk el a szolgáltatást:
systemctl daemon-reload systemctl start print-message.service
Miután elindítottuk a szolgáltatást, nem tapasztalunk semmit. Kérdezzük le a szolgáltatáshoz tartozó naplófájlbejegyzéseket. Erre szolgál a journalctl parancs:
journalctl -u print-message.service -- Logs begin at Tue 2023-05-02 03:04:32 UTC, end at Sat 2023-06-10 12:14:55 UTC. -- Jun 10 12:14:40 pnetlab systemd[1]: Starting Print Message... Jun 10 12:14:40 pnetlab echo[2532882]: Hello, World! Jun 10 12:14:40 pnetlab systemd[1]: print-message.service: Succeeded. Jun 10 12:14:40 pnetlab systemd[1]: Finished Print Message.
Látható, hogy a naplófájlban ott található a kiírt szöveg, de akkor a képernyőn miért nem látjuk? Azért, mert a systemd alapértelmezetten a háttérben indítja el a szolgáltatást, és a kimenetet átirányítja a systemd naplóba.
Most készítsünk egy olyan felülírófájlt, amely még egy üzenetet kiír a képernyőre. Ehhez a korábban megismert edit parancsot használjuk. A szerkesztőbe írjuk be a parancs alatt látható sorokat:
systemctl edit print-message.service [Service] ExecStartPost=/bin/bash -c 'echo "Additional message"'
Az ExecStartPost direktíva használata miatt fog az új üzenet a Hello World! üzenet után megjelenni. Ha előtte akarnánk kiírni, akkor az ExecStartPre direktívát kellene használni.
Ezután már csak újra kell indítani a szolgáltatást, és a naplófájlban megtekinthetjük a két kiírt üzenetet.
systemctl restart print-message.service journalctl -u print-message.service
Futási szintek beállítása a célok (target) segítségével
A cél típusú egységek a rendszer egy-egy olyan állapotát határozzák meg, amelyeknél a szolgáltatások egy adott készlete indul el (pontosabban mondva az erőforrások egy adott készlete töltődik be). A célok egységfájljait a .target utótaggal azonosítjuk. Az Ubuntu rendszeremben például 70 ilyen .target típusú egység található. Nézzünk rájuk pár példát:
- multi-user.target: Ez az alapértelmezett cél, melyben elindul minden olyan szolgáltatás, mely a többfelhasználós üzemmódhoz kell. A rendszer itt várakozik a felhasználó bejelentkezésére.
- graphical.target: Ezt a célt választva a rendszer elindítja az X Windows System-et.
- network.target: A hálózati kapcsolat inicializálásához és beállításához szükséges szolgáltatásokat indítja el.
- shutdown.target: Az aktuális rendszer leállításához szükséges szolgáltatásokat indítja el.
A systemd cél típusú szolgáltatásai felelnek meg az init rendszerek futási szintjeinek, bár ezek sokoldalúbban használhatók, egymással függőségi viszonyban vannak, egyszerre több is betölthető.
Az egyes szolgáltatások egységfájljaiban előírhatjuk, hogy mely célok szükségesek a futásukhoz. Ha például egy olyan szolgáltatást írunk, amely egy grafikus ablakban megjelenít valamit, akkor futásához előírhatjuk a graphical.target futását, vagyis minden olyan szolgáltatás futtatását, amely az X Windows System működéséhez kell.
A systemd rendelkezik egy alapértelmezett céllal, melyet a rendszer indításakor el kell érni. Ezt a get-default paranccsal lehet lekérdezni:
systemctl get-default
Az alapértelmezett cél megváltoztatható a set-default paranccsal. Váltsunk át például a grafikus felületre, vagyis a graphical.target-re. Ilyenkor a rendszer grafikus felülettel töltődik be a következő induláskor. (Feltéve persze, ha minden fel van hozzá telepítve.)
systemctl set-default graphical.target
Listázzuk ki a systemd valamennyi target típusú egységét:
systemctl list-unit-files --type=target
Mindegyik egység a rendszer egy-egy állapotát reprezentálja. Például a printer.target-et ha eléri rendszerindításkor a systemd, akkor elindítja a nyomtatáshoz szükséges szolgáltatásokat. Fontos látni, hogy nem a printer.target tölti be eszeket a szolgáltatásokat, hanem a systemd amikor eléri a printer.target célt, akkor megvizsgálja a függőségi láncot, és betölti mindazokat a szolgáltatásokat, amelyek függnek a printer.target-től. Ha egy ilyen függő szolgáltatás nincsen engedélyezve, akkor 2 dolog történhet: Amennyiben ez a függő szolgáltatás a printer.target függőségének opcionális része, akkor a printer.target betöltődik, de a szolgáltatás nem, hiszen nincsen engedélyezve. Ellenben ha a függő szolgáltatás a printer.target függőségének kötelező része, akkor nem töltődik be a printer.target sem. Ennyiből már jól érzékelhető, hogy a függőségi viszonyokat jól kell beállítani, hiszen egy el nem indult szolgáltatás magával ránthat több más szolgáltatást is.
Lehetőség van arra is, hogy egy adott célhoz rendelt valamennyi szolgáltatás elindítására, illetve mindazok leállítására, amelyek nem részei az adott cél függőségi listájának. Erre szolgál az isolate parancs. Tegyük fel például, hogy grafikus többfelhasználós környezetben dolgozunk, vagyis a graphical.target aktív. Mivel a graphical.target függ a multi-user.target-től, ezért a rendszer betöltésekor a systemd először a multi-user.target-et érte el, és csak utána a graphical.target-et. (Ezt leellenőrizhetjük a list-dependencies paranccsal, érdemes használni a –before és –after kapcsolókat.) Ha most elkülönítjük az isolate paranccsal a multi-user.target-et, akkor a grafikus felület leáll, de a többfelhasználós aktív marad. (Hiszen a grafikus felület szolgáltatásai nem függnek a többfelhasználóstól, tehát azok leállhatnak. Fordítva ez már nem lenne igaz.) Gyakorlatilag ezzel leállítjuk a grafikus felületet.
systemctl isolate multi-user.target
Az egyes célokhoz a könnyebb elérés kedvéért shortcut-ok definiálhatók. Ezeket használhatjuk az isolate parancs helyett. Az egyfelhasználós (single-user, rescue) mód eléréséhez így az isolate parancs, és a shortcut is használható:
systemctl isolate rescue.target systemctl rescue
Ilyen gyakran használt shortcut-ok még a halt (halt.target), poweroff (poweroff.target) és a reboot (reboot.target) is.
Az eddigiekből talán már jól érzékelhető, milyen hasznos eszköz a systemctl a rendszerindítás és a rendszerfolyamatok kezelésének területén.
