systemd (Magyar)

Fordítás állapota: Ez az oldal az angol Systemd című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.02.19. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb módosítások, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.

Adott témakörhöz kapcsolódó oldalak

• systemd (Magyar)/User (Magyar)
• systemd (Magyar)/Timers (Magyar)
• systemd (Magyar)/Journal (Magyar)
• systemd (Magyar)/Sandboxing (Magyar)
• systemd (Magyar)/FAQ (Magyar)
• init (Magyar)
• udev (Magyar)
• Improving performance (Magyar)/Boot process (Magyar)
• Allow users to shutdown (Magyar)

A projekt weboldaláról:

A systemd alapvető építőelemek szoftverkészlete egy Linux-alapú operációs rendszer számára. A systemd rendszerkezelőt és szolgáltatáskezelőt biztosít, amely PID 1 folyamatként fut és elindítja az operációs rendszer többi részét. A systemd agresszív párhuzamosítási képességeket nyújt, socket-aktiválást és D-Bus-aktiválást használ a szolgáltatások elindításához, lehetővé teszi szolgáltatások igény szerinti indítását, nyomon követi a folyamatokat a Linux vezérlőcsoportok segítségével, kezeli a csatolási és automatikus csatolási pontokat, valamint megvalósít egy kifinomult, tranzakcióalapú, függőségeken alapuló szolgáltatásvezérlési logikát. A systemd támogatja a SysV és LSB init szkripteket, és a sysvinit helyettesítőjeként működik. Egyéb részei közé tartozik egy naplózó szolgáltatás, segédprogramok az alapvető rendszerbeállítások kezelésére, mint például a gépnév, dátum, nyelvterületi beállítások, a bejelentkezett felhasználók listájának és a futó konténereknek, valamint virtuális gépeknek a karbantartása, rendszerfiókok, futásidejű könyvtárak és beállítások, továbbá szolgáltatások az egyszerű hálózati beállítás, hálózati időszinkronizáció, naplótovábbítás és névfeloldás kezelésére.

Történelmileg, amit a systemd "szolgáltatásnak" nevez (pont úgy mint Windows alatt), azt Linux alatt a kezdetektől fogva démon néven hívják. (Fordítói megjegyzés: Ezzel feleslegesen, és jól összezavarva mindenkit. Kettő külön név egy ugyanazon dologra.). Lényegében tehát ugyanaz a kettő: Bármely program, amely "háttérfolyamatként" fut (terminál vagy felhasználói felület nélkül), általában események bekövetkeztére várva és szolgáltatásokat nyújtva. Jó példa erre egy webszerver, amely egy weboldal lekérésére vár, vagy egy ssh szerver, amely arra vár, hogy valaki bejelentkezzen. Bár ezek teljes funkcionalitású alkalmazások, vannak démonok, amelyek munkája nem annyira látható. A démonok olyan feladatokat látnak el, mint például üzenetek írása egy naplófájlba (például syslog, metalog), vagy a rendszeridő pontosan tartása (például ntpd). További információért tekintse meg a daemon(7) man súgóleírást.

Megjegyzés A részletes magyarázat elolvasásáért azzal kapcsolatban, hogy az Arch miért váltott át a systemd használatára, tekintse meg ezt a fórumbejegyzést.

Alapvető systemctl használat

A systemctl parancs az a fő parancs amelyet a systemd vizsgálatára és vezérlésére használnak. A systemctl néhány felhasználási módja az operációs rendszer állapotának a vizsgálata, valamint az operációs rendszer és a szolgáltatások kezelése. További részletekért tekintse meg a systemctl(1) man súgóleírást.

Tipp

• Az összes következő systemctl parancs használható a -H user@host kapcsolóval egy távoli számítógépen futó systemd példány vezérlésére. Az említett kapcsoló SSH protokollt használ a távoli systemd példányhoz való kapcsolódáshoz.
• A Plasma felhasználók telepíthetik a systemdgenie szoftvercsomagot, amely grafikus felhasználói felületet biztosít a systemctl számára.

Az unit-fájlok használata

Az unit-fájlok alatt általában (de nem kizárólagosan) a következőket értjük: Szolgáltatások (ilyenkor az unit-fájl .service végződéssel rendelkezik), csatolási pontok (ilyenkor az unit-fájl .mount végződéssel rendelkezik), eszközök (ilyenkor az unit-fájl .device végződéssel rendelkezik) és foglalatok (ilyenkor az unit-fájl .socket végződéssel rendelkezik).

A systemctl parancs használatakor általában meg kell adnia az unit-fájl teljes nevét, beleértve a végződést is, például sshd.socket. Azonban, létezik néhány rövidített forma az unit-fájl megadására a következő systemctl parancsokban:

• Amennyiben Ön nem adja meg az végződést, akkor a systemctl parancs a .service végződést feltételezi. Például a netctl és a netctl.service egyenértékűek.
• A csatolási pontok automatikusan a megfelelő .mount végződésű unit-fájlra lesznek értelmezve. Például a /home megadása egyenértékű a home.mount unit-fájl megadásával.
• Az eszközök (a csatolási pontokhoz hasonlóan) automatikusan a megfelelő .device végződésű unit-fájlra lesznek értelmezve, ezért a /dev/sda2 megadása egyenértékű a dev-sda2.device unit-fájl megadásával.

A részletekért tekintse meg a systemd.unit(5) man súgóleírást.

Megjegyzés Néhány unit-fájl neve tartalmaz egy @ jelet (pl. név@string.service): Ez azt jelenti, hogy ezek a fájlok egy sablon unit-fájl példányai, amelynek tényleges fájlneve nem tartalmazza a string részt (pl. név@.service). A string karakterláncot példányazonosítónak nevezzük, és hasonló egy argumentumhoz, amelyet a systemctl paranccsal meghívott sablon unit-fájl kap meg: A sablon unit-fájlba a %i specifikátort fogja behelyettesíteni. Pontosabban, még mielőtt a systemd megpróbálná példányosítani a név@.utótag sablon unit-fájlt, maga a systemd megkeres egy olyan unit-fájlt, amelynek pontos fájlneve név@string.utótag. (Bár konvenció szerint az ilyen "ütközés" ritkán fordul elő). Tehát a legtöbb @ jelet tartalmazó unit-fájl sablonnak van szánva. Továbbá, ha egy sablon unit-fájlt példányazonosító nélkül hívnak meg, akkor az általában hibát eredményez (kivéve bizonyos systemctl parancsoknál, mint például a cat).

Az alábbi táblázatban szereplő parancsok rendszerszintű unit-fájlokon működnek, mivel a --system az systemctl parancs esetében az alapértelmezett beállítás. Amennyiben Ön a felhasználói szintű unit-fájlokon (az aktuális felhasználónál) szeretne műveletet végezni, akkor használja a systemctl --user parancsot root jogosultság nélkül. Tekintse meg a systemd/User#Alapbeállítás című leírást is, ahol minden felhasználó számára engedélyezheti vagy letilthatja a felhasználói szintű unit-fájlokat.

Tipp

• A legtöbb parancs akkor is működik, amikor több unit-fájl van megadva. További információért tekintse meg a systemctl(1) man súgót.
• A --now kapcsoló együtt használható az enable, disable és mask parancsokkal, annak érdekében, hogy az unit-fájl azonnal el legyen indítva, le legyen állítva vagy maszkolva legyen, ahelyett, hogy a számítógépet újra kellene indítani.
• Egy szoftvercsomag különböző célokra kínálhat unit-fájlokat. Amennyiben Ön éppen feltelepített egy szoftvercsomagot, akkor a pacman -Qql szoftvercsomagnév | grep -Fe .service -e .socket parancs használható az unit-fájlok ellenőrzésére és megtalálására.
• Ha elérhető, akkor az unit.socket engedélyezése az unit.service helyett előnyös lehet, mert a socket szükség esetén elindítja a szolgáltatást. További részletekért tekintse meg a #Socket aktiválása című leírást.

Művelet	Parancs	Megjegyzés
A rendszer állapotának elemzése
Rendszer állapotának megjelenítése	systemctl status
Azon unit-fájlok listázása, amelyek épp futnak	systemctl vagy systemctl list-units
Azon unit-fájlok listázása, amelyeknek nem sikerült elindulniuk	systemctl --failed
Azon unit-fájlok listázása, amelyek telepítve lettek1	systemctl list-unit-files
Egy PID folyamatállapotának megjelenítése	systemctl status pid	cgroup szelet, memória és a szülő
Az unit-fájl állapotának ellenőrzése
Egy szóban forgó unit-fájl súgójának megjelenítése	systemctl help unit	Ahogyan az unit-fájl támogatja
Egy szóban forgó unit-fájl állapota	systemctl status unit	Beleértve azt is, hogy fut-e vagy sem
Annak ellenőrzése, hogy az unit-fájl engedélyezve van-e	systemctl is-enabled unit
Az unit-fájl elindítása, újraindítása, újbóli betöltése
Az unit-fájl azonnali elindítása	systemctl start unit mint root felhasználó
Az unit-fájl futásának azonnali megállítása	systemctl stop unit mint root felhasználó
Az unit-fájl újraindítása	systemctl restart unit mint root felhasználó
Az unit-fájl és a hozzá tartozó beállítás újbóli betöltése	systemctl reload unit mint root felhasználó
A systemd manager beállításának újbóli betöltése2	systemctl daemon-reload mint root felhasználó	Új vagy megváltozott unit-fájlok keresése esetén
Az unit-fájl engedélyezése
Annak engedélyezése, hogy az unit-fájl automatikusan elinduljon mindig a bootoláskor	systemctl enable unit mint root felhasználó
Annak engedélyezése, hogy az unit-fájl automatikusan elinduljon mindig a bootoláskor, majd most azonnal induljon el az unit-fájl	systemctl enable --now unit mint root felhasználó
Annak letiltása, hogy az unit-fájl automatikusan elinduljon mindig a bootoláskor	systemctl disable unit mint root felhasználó
Annak letiltása, hogy az unit-fájl automatikusan elinduljon mindig a bootoláskor, majd most azonnal álljon meg az unit-fájl futása	systemctl disable --now unit mint root felhasználó
Az unit-fájl újbóli engedélyezése3	systemctl reenable unit mint root felhasználó	Páldául, az unit-fájl letiltása és egy új únit-fájl engedélyezése esetén
Egy unit-fájl létrehozása
Egy unit-fájl kimaszkolása, annak érdekében, hogy ezáltal ne lehessen az unit-fájlt elindítani4	systemctl mask unit mint root felhasználó
Egy unit-fájl kimaszkolásának visszavonása	systemctl unmask unit mint root felhasználó

1. Tekintse meg a systemd.unit(5) § UNIT FILE LOAD PATH man súgót azokhoz a könyvtárakhoz, ahol az elérhető unit-fájlok megtalálhatók.
2. Ez nem kéri meg a megváltozott unit-fájlokat, hogy újratöltsék saját beállításaikat. (Tekintse meg az Újbóli betöltés műveletet).
3. Például, amikor az [Install] szekciója megváltozott amióta az utoljára engedélyezve volt.
4. A kimaszkolás veszélyes manuális úton is, és függőségként is. Ellenőrizze a meglévő maszkolt unit-fájlokat a következő paranccsal:

   $ systemctl list-unit-files --state=masked

Energiakezelés

A polkit szükséges az energiakezeléshez olyan felhasználó számára amely felhasználó nem rendelkezik megemelt felhasználói jogosultságokkal. Amennyiben Ön egy helyi systemd-logind felhasználói munkamenetben van benne, és a rendszeren nincs más aktív munkamenet, akkor a következő parancsok root felhasználói jogosultság nélkül is működni fognak. Ha a rendszeren van más aktív munkamenet (például mert egy másik felhasználó be van jelentkezve egy tty-be), akkor a systemd automatikusan elkéri Öntől a root felhasználó jelszavát.

Művelet	Parancs
Rendszer leállítása és újbóli elindítása.	systemctl reboot
Rendszer leállítása és kikapcsolása.	systemctl poweroff
Rendszer felfüggesztése.	systemctl suspend
Rendszert hibernált állapotba teszi. (RAM memória tartalmát kiírja az adathordozóra.)	systemctl hibernate
Hybrid-sleep állapotba helyezi a rendszert. (Más néven suspend-to-both. RAM memóriát ment az adathordozóra, majd felfüggeszti a működést.)	systemctl hybrid-sleep
Először felfüggeszti a rendszert, majd egy beállított idő elteltével felébreszti a rendszert hibernálás céljából.	systemctl suspend-then-hibernate
Végrehajtja egyedül a felhasználói tér újraindítását egy #Soft reboot paranccsal.	systemctl soft-reboot

Soft reboot

A Soft reboot egy speciális, egyedül a felhasználói térben végrehajtott újraindítási művelet, amely nem érinti a kernelt. A systemd-soft-reboot.service(8) szolgáltatás implementálja, és a systemctl soft-reboot paranccsal hívható meg. A kexec rendszerhíváshoz hasonlóan kihagyja a firmware újrainicializálását, de ezen felül a rendszer nem megy át a kernel inicializálásán és az initramfs fájlrendszeren sem, valamint a feloldott dm-crypt adathordozók is felcsatolva maradnak a fájlrendszerben.

Amikor a /run/nextroot/ könyvtár egy érvényes gyökérfájlrendszer hierarchiát tartalmaz (például egy másik disztribúció vagy egy másik pillanatkép gyökérkönyvtárának felcsatolása), akkor a soft-reboot átváltja a rendszer gyökérkönyvtárát abba a hierarchiába, lehetővé téve egy másik telepítésre való váltást anélkül, hogy elvesznének a kernel által kezelt állapotok, például a hálózatkezelés.

Tipp A /run/nextroot/ könyvtár nem támogatott feltétlenül csatolási pont vagy fizikai eszköz által. Például a /run/ tmpfs könyvtárban is elhelyezkedhet. A systemd a soft-reboot során automatikusan csatolási ponttá alakítja a /run/nextroot/ könyvtárat.

Megjegyzés Ne használja a systemctl soft-reboot parancsot olyan szoftvercsomag-frissítések után, amelyek érintették a kernelt és az initramfs fájlrendszert.

Az unit-fájlok írása

A systemd unit-fájlok (systemd.unit(5)) szintaxisát a XDG Desktop Entry Specification .desktop fájlok ihlették, amelyeket viszont a Microsoft Windows .ini fájlok inspiráltak. Az unit-fájlok több könyvtárból töltődnek be a számítógép memóriájába (a teljes lista megtekintése érdekében futtassa a systemctl show --property=UnitPath parancsot), de a fő könyvtárak a következők (a legalacsonyabbtól a legmagasabb prioritásig felsorolva):

• A feltelepített szoftvercsomagban lévő unit-fájlok a /usr/lib/systemd/system/ könyvtárból töltődnek be a számítógép memóriájába.
• A rendszergazda által feltelepített unit-fájlok a /etc/systemd/system/ könyvtárból töltődnek be a számítógép memóriájába.

Megjegyzés

• Amikor a systemd user módban fut, akkor a betöltési útvonalak teljesen eltérőek.
• A systemd unit-fájlok nevei egyedül ASCII alfanumerikus karaktereket, aláhúzásokat és pontokat tartalmazhatnak. Minden más karaktert C-stílusú "\x2d" escape szekvenciával kell helyettesíteni, vagy előre meghatározott szemantikájukat kell alkalmazni ('@', '-'). Tekintse meg a systemd.unit(5) és systemd-escape(1) súgókat a további információkért.

Példaként, nézze meg az Ön szoftvercsomagjai által a számítógépre feltelepített unit-fájlokat, valamint systemd.service(5) § EXAMPLES man súgót.

Tipp A kettős kereszt (#) jellel kezdődő megjegyzéseket az unit-fájlokban is használni lehet. Fontos tudni, hogy csak az új sorokban szabad használni a megjegyzéseket. A systemd paraméterek után, a sorok végénél egyáltalán ne használjon megjegyzéseket, máskülönben az unit-fájl nem fog aktiválódni.

A systemd-analyze(1) parancs segíthet a munka ellenőrzésében. Tekintse meg a parancshoz tartozó man súgóban a systemd-analyze verify FILE... című leírást.

Az unit-fájlok függőségeinek kezelése

A systemd segítségével az unit-fájlok függősei megoldhatók a megfelelően megtervezett unit-fájlokkal. A legtipikusabb eset az, amikor az A unit-fájlnak szüksége van arra, hogy a B unit-fájl már fusson, még mielőtt az A unit-fájl elindul. Ebben az esetben adja hozzá a Requires=B és a After=B bejegyzéseket az A [Unit] szakaszához. Ha opcionális az unit-fájl függősége, akkor inkább a Wants=B és a After=B bejegyzéseket adja hozzá a szakaszhoz. Fontos megjegyezni, hogy a Wants= és a Requires= nem jelentik automatikusan a After= beállítást, tehát ha a After= nincs megadva, akkor a kettő unit-fájl párhuzamosan fog elindulni.

Az unit-fájlok függőségeit általában szolgáltatásokhoz rendelik hozzá, nem pedig target fájlokhoz. Például a network.target fájlt bármelyik szolgáltatás behúzza függőségként, amely a hálózati interfészeket állítja be, ezért elegendő, hogy az Ön saját unit-fájlját utána rendezi, mivel a network.target fájl mindenképpen elindul.

A .service fájlok típusai

Számos különböző elindítási típust kell figyelembe venni egy egyedi szolgáltatásfájl (.service) megírásakor. Az elindítási típust a Type= paraméterrel lehet beállítani a [Service] szakaszban:

• Type=simple (alapértelmezett) — A systemd azonnal elindultnak tekinti a szolgáltatást. A folyamat nem ágazhat el. Ha más szolgáltatásokat ennek a szolgáltatásnak a sorrendjébe kell állítani, akkor ne használja ezt a típust, kivéve ha socket aktivált.
• Type=forking — A systemd akkor tekinti elindultnak a szolgáltatást, amikor a folyamat elágazik és a szülőfolyamat befejeződött. Klasszikus szolgáltatásokhoz Ön ezt a típust használja, hacsak nem tudja, hogy nincs rá szükség. Meg kell adnia a PIDFile= paramétert is annak érdekében, hogy a systemd nyomon tudja követni a fő folyamatot.
• Type=oneshot — Hasznos olyan szkriptekhez, amelyek egyetlen feladatot végeznek el, majd befejeződnek. Érdemes beállítani a RemainAfterExit=yes paramétert is annak érdekében, hogy a systemd a folyamat befejeződése után is aktívnak tekintse a szolgáltatást. A RemainAfterExit=yes beállítása megfelelő azokhoz az unit-fájlokhoz, amelyek megváltoztatják a rendszer állapotát (például egy partíció felcsatolása). Tekintse meg a ezt a leírást a simple és oneshot közötti különbségekkel kapcsolatban.
• Type=notify — Megegyezik a Type=simple típussal, de azzal a kikötéssel, hogy a szolgáltatás jelet küld a systemd számára, amikor készen áll. Ennek az értesítésnek a referencia-implementációját a libsystemd-daemon.so biztosítja.
• Type=dbus — Szolgáltatás akkor tekinthető készenléti állapotúnak, amikor a megadott BusName megjelenik a DBus rendszerbuszon.
• Type=idle — A systemd késlelteti a szolgáltatás binárisának végrehajtását mindaddig, amíg az összes feladat kiosztásra nem kerül, hacsak ezek nem tartanak tovább 5 másodpercnél, amely esetben a szolgáltatás binárisa mindenképpen elindul. Ettől eltekintve a viselkedése nagyon hasonló a Type=simple típushoz. Soha nem szabad szolgáltatások sorrendjéhez használni, és a parancssori kimenet olvashatóságának javítására szolgál.

Tekintse meg a systemd.service(5) § OPTIONS man súgót a Type értékek részletesebb magyarázatáért.

A már létező unit-fájlok szerkesztése

A pacman szoftvercsomag-kezelővel való ütközések elkerülése érdekében a már létező, a szoftvercsomagok által biztosított unit-fájlokat nem szabad közvetlenül szerkeszteni. Kettő biztonságos módja van egy unit-fájl módosításának az eredeti unit-fájl érintése nélkül: Az első esetben létre kell hozni egy új unit-fájlt, amely felülírja az eredeti unit-fájl. A második esetben beilleszthető kódrészleteket kell létrehozni, amely kódrészletek az eredeti unit-fájl tetejére kerülnek alkalmazásra. Mindkét módszer esetén újból be kell tölteni az unit-fájlt a számítógép memóriájába annak érdekében, hogy a változtatások érvénybe lépjenek. A memóriába történő újbóli betöltés elvégezhető a unit-fájl szerkesztésével a systemctl edit paranccsal (ami automatikusan újból betölti a memóriába az unit-fájlt). Továbbá, a memóriába történő újbóli betöltés elvégezhető az összes unit-fájl memóriába történő újbóli betöltésével is, amelyet az alábbi paranccsal lehet elvégezni:

# systemctl daemon-reload

Tipp

• A systemd-delta parancs használatával Ön meg tudja nézni, hogy mely unit-fájlok lettek felülírva vagy kiegészítve, és pontosan mi változott bennük.
• Használja a systemctl cat unitneve parancsot egy unit-fájl tartalmának megtekintéséhez, és az összes kapcsolódó beilleszthető kódrészlet megtekintéséhez.

Az unit-fájlok felülírása

A /usr/lib/systemd/system/unit unit-fájl lecserélése érdekében hozza létre a /etc/systemd/system/unit fájlt, majd engedélyezze újra az unit-fájlt a szimbolikus linkek frissítéséhez.

Alternatívaként, futtassa a következő parancsot:

# systemctl edit --full unit

A fenti parancs megnyitja a /etc/systemd/system/unit fájlt a szövegszerkesztőben (amennyiben a fájl még nem létezik, akkor a fenti parancs a fájl feltelepített verzióját másolja), és amikor Ön befejezi a fájl szerkesztését, akkor a fenti parancs automatikusan újból betölti a számítógép memóriájába az unit-fájlt.

Megjegyzés A helyettesítő unit-fájlok továbbra is használatban maradnak, még akkor is, amikor a jövőben a pacman szoftvercsomag-kezelő frissíti az eredeti unit-fájlt. Ez a módszer megnehezíti az operációs rendszer karbantartását, ezért a következő megközelítés van előnyben részesítve.

Beilleszthető kódrészletfájlok

A /usr/lib/systemd/system/unit unit-fájlhoz tartozó beilleszthető kódrészletfájlok (drop-in fájlok) létrehozása érdekében, először hozza létre a /etc/systemd/system/unit.d/ könyvtárat, majd helyezze el oda a .conf fájlokat a beállítások felülbírálása érdekében vagy az új beállítások hozzáadása érdekében. A systemd ezeket a kódrészletfájlokat elemezni fogja és az eredeti unit-fájl fölé fogja helyezi őket.

Ennek legegyszerűbb módja a következő parancs futtatása:

# systemctl edit unit-fájl_neve --drop-in=beilleszthető_kódrészletfájl_neve

A fenti parancs szerkesztés céljából megnyitja a /etc/systemd/system/unit-fájl_neve.d/beilleszthető_kódrészletfájl_neve.conf fájlt a szövegszerkesztőben (ha előtte nem létezett a fájl, akkor létrehozza az újat), és automatikusan újratölti az unit-fájlt a memóriában, amikor Ön befejezte a fájl szerkesztését. A --drop-in= opció elhagyása esetén a systemd az alapértelmezett fájlnevet override.conf fogja használni.

Megjegyzés

• A kulcsot továbbra is a megfelelő szakaszba kell elhelyezni az override fájlban.
• Nem minden kulcs írható felül beilleszthető kódrészletfájlokkal. Például a Conflicts= módosításához egy helyettesítő fájl szükséges.
• Ön használhat felső szintű beilleszthető kódrészletfájlokat annak érdekében, hogy minden azonos típusú unit-fájlra hasson. Például egy beilleszthető kódrészletfájl a /etc/systemd/system/service.d/ könyvtárban minden .service unit-fájlt érint. Az #Értesítés a meghibásodott szolgáltatásfájlokról című leírásban láthat egy példát.

Az unit-fájl visszaállítása az eredeti verzióra

Annak érdekében, hogy az unit-fájlon a systemctl edit használatával végrehajtott módosítások visszavonásra kerüljenek, tegye a következőt:

# systemctl revert unit

Példák

Pédául, ha Ön egyszerűen csak egy további függőséget szeretne hozzáadni egy unit-fájlhoz, akkor létrehozhatja a következő fájlt:

/etc/systemd/system/unit.d/customdependency.conf

[Unit]
Requires=new dependency
After=new dependency

Egy másik példaként, az ExecStart direktíva lecserélése érdekében hozza létre a következő fájlt:

/etc/systemd/system/unit.d/customexec.conf

[Service]
ExecStart=
ExecStart=new command

Figyelje meg, hogy az ExecStart direktívát törölni kell, mielőtt újra hozzárendelné [1]. Ugyanez vonatkozik minden olyan elemre, amely többször is megadható, például az .timer unit-fájlokhoz tartozó OnCalendar direktívára is vonatkozik.

Még egy példa egy szolgáltatás automatikus újraindítására:

/etc/systemd/system/unit.d/restart.conf

[Service]
Restart=always
RestartSec=30

Szolgáltatások naplózási szintjei

Azoknál a szolgáltatásoknál, amelyek közvetlenül a journald vagy a syslog felé küldenek naplóadatokat, szabályozható a naplózás részletessége azáltal, hogy a [Service] szekcióban, a LogLevelMax= paraméterhez egy 0 és 6 közötti numerikus értéket állítunk be a fent leírt módszerek használatával. Például:

/etc/systemd/system/unit.d/override.conf

[Service]
LogLevelMax=3

A szabványos naplózási szintek megegyeznek a journal szűrési szintjeivel. Alacsonyabb szám beállítása kizárja az összes magasabb és kevésbé fontos naplóüzenetet a journal-ból.

Egy szolgáltatás szabványos kimenetének elnyomása

Ha egy szolgáltatás a stdout és/vagy stderr kimenetre ír, akkor alapértelmezés szerint ez a journal-ban is megjelenik. Ez a viselkedés elnyomható a [Service] szekcióban a StandardOutput=null és/vagy a StandardError=null beállításával. A null értéken kívül más értékek is használhatók a viselkedés további finomhangolása szempontjából. Tekintse meg a systemd.exec(5) § LOGGING_AND_STANDARD_INPUT/OUTPUT man súgóleírást.

A target végződésű unit-fájlok

A systemd a .target végződésű unit-fájlokat használja az unit-fájlok függőségeken keresztüli csoportosítására és szabványosított szinkronizációs pontokként való használatra. Ezek a fájlok hasonló célt szolgálnak, mint a futásszintek, de kissé eltérően működnek. Minden target névvel van ellátva, nem számmal, és egy adott célra szolgál, azzal a lehetőséggel, hogy egyszerre több is aktív legyen. Néhány target úgy van megvalósítva, hogy örökli egy másik target összes szolgáltatását, és további szolgáltatásokat ad hozzá. Vannak olyan systemd target fájlok, amelyek a megszokott SystemVinit futásszinteket utánozzák.

Számítógépre feltelepített target fájlok listázása

A runlevel futtatása helyett, a systemd alatt a következő parancsot kell futtatni:

$ systemctl list-units --type=target

Egyedi target létrehozása

A futásszintek, amelyeknek meghatározott jelentésük volt sysvinit alatt (azaz 0, 1, 3, 5 és 6), 1:1 megfeleltetésben állnak egy adott systemd target fájlal. Sajnos, mint például a 2 és 4., nincs megfelelő módszer ugyanerre a felhasználó által definiált futásszintek esetében. Ha Ön ezeket használja, akkor javasolt, hogy hozzon létre egy új, névvel ellátott systemd target fájlt /etc/systemd/system/az_Ön_target_fájljának_a_neve néven, amely valamelyik meglévő futásszintet veszi alapul (példaként megtekintheti a /usr/lib/systemd/system/graphical.target fájlt). Aztán, hozzon létre egy könyvtárat /etc/systemd/system/az_Ön_target_fájljának_a_neve.wants, majd szimbolikus linkekkel kapcsolja hozzá azokat a további szolgáltatásokat a /usr/lib/systemd/system/ könyvtárból, amelyeket engedélyezni kíván.

SysV futásszintek és systemd target fájlok megfeleltetése

SysV futási szint	systemd target	Megjegyzések
0	poweroff.target	Rendszer leállítása.
1, s, single	rescue.target	Egyfelhasználós mód.
2, 4	multi-user.target	Felhasználó által definiált/helyszín-specifikus futási szintek. Alapértelmezés szerint megegyezik a 3. szinttel.
3	multi-user.target	Többfelhasználós, nem grafikus felhasználói felülettelű. A felhasználók általában több parancssorban vagy hálózaton keresztül is bejelentkezhetnek.
5	graphical.target	Többfelhasználós, grafikus felhasználói felületű. Általában a 3. futási szint összes szolgáltatásával rendelkezik. Továbbá, grafikus felhasználói felületről történő bejelentkezéssel is rendelkezik.
6	reboot.target	Újraindítás.
emergency	emergency.target	Vészhelyzeti parancssor.

Az aktuális target megváltoztatása

A systemd esetében a target-eket Ön a target unit-fájlok formájában érheti el. Ezeket így tudja megváltoztatni:

# systemctl isolate graphical.target

A fenti parancs egyedül az aktuális target fájlt változtatja meg, és nincs hatással a következő rendszerindításra. A fenti parancs egyenértékű a Sysvinit esetében használt parancsokkal, mint például telinit 3 vagy telinit 5.

Alapértelmezett target megváltoztatása, amelybe a rendszer bootoláskor belép

A standard target a default.target, amely egy szimbolikus hivatkozás a graphical.target target fájlra. Ez a target nagyjából megfelel a régi 5-ös futási szintnek.

Asystemctl paranccsal történő jelenlegi target ellenőrzése érdekében a következőt kell tenni:

$ systemctl get-default

Az alapértelmezett target megváltoztatása érdekében, amelybe a rendszer bootoláskor betölt, módosítani kell a default.target szimbolikus hivatkozást. A systemctl parancs használatával a következőt kell megtenni:

# systemctl set-default multi-user.target

Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.

Alternatív megoldásként, a következő kernel paraméter közül a egyiket adja hozzá az Ön boot loader programjához:

• systemd.unit=multi-user.target (Ami nagyjából megfelel a régi 3. futási szintnek.)
• systemd.unit=rescue.target (Ami nagyjából megfelel a régi 1. futási szintnek.)

Alapértelmezett target-sorrend

A systemd a default.target fájlt a következő sorrend alapján választja ki:

1. Kernelparaméter, ahogy fent látható.
2. A /etc/systemd/system/default.target fájl szimbolikus linkje.
3. A /usr/lib/systemd/system/default.target fájl szimbolikus linkje.

A systemd komponensek

A systemd néhány komponense a következő (a lita nem teljes):

• kernel-install — A kernelek és a hozzájuk tartozó initramfs binárisan futtatható képfájlok automatikus áthelyezése a boot partícióra.
• systemd-analyze(1) — A bootolási teljesítmény meghatározására használható. Továbbá, használható a statisztikák és egyéb állapot információk, valamint nyomkövetési információk lekérésére. Használható az unit-fájlok helyességének ellenőrzésére. Továbbá speciális funkciókhoz is hozzáférést biztosít, amelyek hasznosak a haladószintű hibakeresés szempontjából.
• systemd-boot — Egyszerű UEFI boot manager.
• systemd-creds — A systemd unit-fájlok által használt hitelesítési adatok biztonságos tárolása és visszakeresése.
• systemd-cryptenroll — PKCS#11, FIDO2, TPM2 tokenek/eszközök regisztrálása LUKS2 titkosított kötetekhez.
• systemd-firstboot — Alapvető rendszerbeállítások inicializálása az első bootolás előtt.
• systemd-homed — Hordozható felhasználói fiókok.
• systemd-logind(8) — Munkamenet-kezelés.
• systemd-networkd — Hálózatkezelés.
• systemd-nspawn — Könnyűsúlyú névtér-konténer.
• systemd-repart — Partíciós táblázatok létrehozása, partíciók hozzáadása vagy bővítése.
• systemd-resolved — Hálózati névfeloldás.
• systemd-run(1) / run0 — Ideiglenesen és interaktívan emelt vagy eltérő jogosultságok megszerzése.
• systemd-stub(7) — UEFI boot stub unified kernel image binárisan futtatható képfájlok létrehozásához.
• systemd-sysusers(8) — Rendszerfelhasználók és csoportok létrehozása, valamint felhasználók csoportokhoz adása csomagtelepítéskor vagy rendszerindításkor.
• systemd-timesyncd — Rendszeridő hálózati szinkronizációja.
• systemd/Journal — Rendszer naplózása.
• systemd/Timers — Monoton vagy valós idejű időzítők .service fájlok vagy események vezérlésére. A cron program észszerű alternatívája.

Fájlrendszer felcsatolása a futó fájlrendszerbe systemd.mount használatával

A systemd felelős a /etc/fstab fájlban megadott partíciók és fájlrendszerek felcsatolásáért. A systemd-fstab-generator(8) az összes bejegyzést a /etc/fstab fájlból átalakítja systemd unit-fájlokká. Ez a folyamat a rendszer bootolásakor, valamint a rendszerkezelő beállításának újbóli betöltésekor történik meg.

A systemd kiterjeszti a szokásos fstab képességeket, és további csatolási opciókat kínál. Ezek az opciók befolyásolják a csatolási unit-fájl függőségeit. Például az opciók biztosíthatják, hogy egy csatolás egyedül akkor történjen meg, amikor a hálózat már működik, vagy amikor egy másik partíció már fel lett csatolva az éppen működésben lévő fájlrendszerbe. A teljes lista a speciális systemd csatolási opciókról, amelyek jellemzően x-systemd. előtaggal kezdődnek, részletesen megtalálható a systemd.mount(5) § FSTAB man súgóleírásban.

Ezeknek a csatolási opcióknak egy példája az automatikus csatolás (automounting), amely azt jelenti, hogy a csatolás egyedül akkor történik meg, amikor az erőforrásra valóban szükség van, nem pedig automatikusan a rendszer bootolásakor. Ez a lehetőség az fstab#Automatikus felcsatolás a systemd segítségével című leírásban található.

GPT partíció automatikus úton történő felcsatolása a futó fájlrendszerbe

Az UEFI-vel bootolt rendszereken a GPT partíciók, mint például a root, home, swap stb., automatikusan felcsatolhatók a Discoverable Partitions Specification alapján. Ennek köszönhetően ezek a partíciók kihagyhatók az fstab fájlból, és amennyiben a root partíció automatikusan felcsatolódik, akkor a root= is elhagyható a kernelparancssorból. Tekintse meg a systemd-gpt-auto-generator(8) man súgót.

Következők az előfeltételek:

• Az mkinitcpio használatakor szükséges a systemd hook a root partíció automatikus úton történő felcsatolása érdekében.
• Minden automatikusan felcsatolt partíciónak ugyanazon a fizikai adathordozón kell lennie, mint amelyen az ESP partíció van.
• A megfelelő GPT partíciótípusokat kell beállítani. Tekintse meg a Partitioning#Particionálási séma című leírást.
• A boot loader programnak be kell állítania a LoaderDevicePartUUID EFI változót annak érdekében, hogy az adott EFI rendszerpartíció azonosítható legyen. Ezt támogatja a systemd-boot, systemd-stub(7), Limine, GRUB (grub-mkconfig által generált grub.cfg, egyéni grub.cfg esetén szükséges a bli modul betöltése) és rEFInd (alapértelmezetten nincs engedélyezve). Ez ellenőrizhető a bootctl futtatásával, és annak vizsgálatával, hogy van-e Partition: sor a Current Boot Loader vagy Current Stub alatt, amikor Unified kernel image segítségével történik a bootolás.

Az udev létrehozza a felfedezett partíciókra mutató szimbolikus linkeket, amelyek használhatók a partíciók és kötetek hivatkozására a beállításfájlokban.

Tipp Egy partíció automatikus úton történő felcsatolása letiltható a partíció GUID típus módosításával, vagy a 63-as partícióattribútum bit ("do not automount") beállításával. Tekintse meg a gdisk#Prevent GPT partition automounting című leírást.

/var

A /var könyvtár automatikus úton történő felcsatolása érdekében a PARTUUID azonosítónak meg kell egyeznie a partíciótípus UUID (machine ID) gépazonosítóval kulcsolt SHA256 HMAC hash értékével. A szükséges PARTUUID azonosító az alábbi módon szerezhető be:

$ systemd-id128 -u var-partition-uuid

Megjegyzés A systemd-id128(1) az /etc/machine-id fájlból olvassa ki a gépazonosítót, ezért a szükséges PARTUUID azonosító nem határozható meg az operációs rendszer feltelepítése előtt.

systemd-sysvcompat

A systemd-sysvcompat szoftvercsomagban lévő systemd-sysvcompat program (amelyet a base szoftvercsomag igényel) elsődleges szerepe a hagyományos linux init bináris program meglétének a biztosítása. A systemd által vezérelt operációs rendszereken az init csupán egy szimbolikus link a systemd végrehajtható fájljára.

Ezenfelül, négy kényelmi parancsikont is biztosít, amelyeket a SysVinit felhasználók megszokhattak. A kényelmi parancsikonok: halt(8), poweroff(8), reboot(8) és shutdown(8). Mind a négy parancs szimbolikus link a systemctl programhoz, és a systemd működése szabályozza őket. Ezért az #Energiakezelés című szakaszban tárgyaltak érvényesek.

A systemd-alapú operációs rendszerek lemondhatnak ezekről a System V kompatibilitási módszerekről az init= boot paraméter használatával és a systemd natív systemctl parancsargumentumaival. (Tekintse meg ezt a példát: /bin/init is in systemd-sysvcompat ?)

systemd-tmpfiles - ideiglenes fájlok

A systemd-tmpfiles létrehozza, törli és megtisztítja az illékony és ideiglenes fájlokat és könyvtárakat. A systemd-tmpfiles a /etc/tmpfiles.d/ és a /usr/lib/tmpfiles.d/ beállításfájlokat olvassa be annak érdekében, hogy meghatározza, mely műveleteket kell végrehajtani. Az előbbi könyvtárban lévő beállításfájlok elsőbbséget élveznek az utóbbi könyvtárban lévő beállításfájlokkal szemben.

A beállításfájlok általában a szolgáltatásfájlokkal együtt vannak szállítva, és /usr/lib/tmpfiles.d/program.conf stílusban vannak elnevezve. Például a Samba szolgáltatás elvárja, hogy a /run/samba könyvtár létezzen és megfelelő jogosultságokkal rendelkezzen. Ezért a samba szoftvercsomag a következő beállítással érkezik:

/usr/lib/tmpfiles.d/samba.conf

D /run/samba 0755 root root

A beállításfájlok arra is használhatók, hogy a számítógép bootolásakor bizonyos fájlokba értékeket írjanak. Például, amikor Ön a /etc/rc.local fájlt használta arra, hogy letiltsa az USB-eszközökről történő ébresztést a echo USBE > /proc/acpi/wakeup paranccsal, akkor a következő tmpfile-t használhatja helyette:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w    /proc/acpi/wakeup     -    -    -    -   USBE

Lehetséges több sort írni ugyanabba a fájlba, akár az argumentumban lévő \n használatával, akár a w+ típus alkalmazásával több sorban (beleértve az elsőt is) a hozzáfűzéshez:

/etc/tmpfiles.d/disable-usb-wake.conf

#    Path                  Mode UID  GID  Age Argument
w+   /proc/acpi/wakeup     -    -    -    -   USBE
w+   /proc/acpi/wakeup     -    -    -    -   LID0

A részletekért tekintse meg a systemd-tmpfiles(8) és a tmpfiles.d(5) man súgókat.

Megjegyzés Ez a módszer nem feltétlenül működik a beállítások megadására a /sys könyvtárban, mivel a systemd-tmpfiles-setup szolgáltatás lefuthat, mielőtt a megfelelő eszközmodulok betöltődnének. Ebben az esetben Ön ellenőrizheti, hogy a modul rendelkezik-e paraméterrel a kívánt beállításhoz a modinfo module paranccsal, és ezt a beállítást megadhatja egy beállításfájlban az /etc/modprobe.d könyvtárban. Ellenkező esetben Önnek udev szabályt kell írnia annak érdekében, hogy a megfelelő attribútum beállításra kerüljön, amint az eszköz megjelenik.

Beilleszthető kódrészletfájlok beállításfájljai

A szoftvercsomagok által biztosított beállításfájlokat nem szabad közvetlenül szerkeszteni, azért, hogy ezáltal el legyenek kerülve az ütközések a pacman frissítésekkel. A beállítás módosítására sok (de nem mindegyik) systemd szoftvercsomag lehetőséget ad anélkül, hogy az eredeti fájlt beilleszthető kódrészletek létrehozásával érintené. Ellenőrizze a szoftvercsomag man súgóját annak érdekében, hogy a szoftvercsomag támogatja-e a beilleszthető kódrészletfájlok beállításfájljait.

Ahhoz, hogy Ön létrehozzon egy beilleszthető kódrészlet beállításfájlt az /etc/systemd/unit.conf unit-fájlhoz, hozza létre a /etc/systemd/unit.conf.d/ könyvtárat, és helyezze el ott a .conf fájlokat az opciók felülírása érdekében vagy új opciók hozzáadása érdekében. A systemd ezeket a fájlokat az eredeti unit-fájl fölött értelmezi és alkalmazza.

Az általános beállítás ellenőrzése:

$ systemd-analyze cat-config systemd/unit.conf

A fenti parancs kimenetében az alkalmazott beilleszthető kódrészlet fájl(ok) és tartalom a végén lesznek felsorolva. A változtatások életbeléptetése érdekében indítsa újra a szolgáltatást.

Tippek és trükkök

Socket aktiválása

Néhány szoftvercsomag .socket unit-fájlt biztosít. Például a cups szoftvercsomag biztosítja a cups.socket unit-fájlt[2]. Ha a cups.socket engedélyezett állapotban van (és a cups.service le van tiltva), akkor a systemd nem indítja el azonnal a CUPS programot, egyedül a megfelelő socketeket figyeli. Ezután, amikor egy program megpróbál csatlakozni valamelyik CUPS sockethez, akkor a systemd elindítja a cups.service szolgáltatást, és átlátható módon átadja az irányítást ezek felett a portok felett a CUPS folyamatnak.

Grafikus felhasználói felülettel rendelkező beállítást segítő alkalmazások

• systemadm — Grafikus felhasználói felülettel (GUI) rendelkező böngésző a systemd unit-fájlok számára. Meg tudja jeleníteni az unit-fájlok listáját. Tud típus szerint szűrni.

https://github.com/systemd/systemd-ui || systemd-ui

• systemdGenie — KDE technológiát használó systemd kezelő segédalkalmazás.

https://apps.kde.org/systemdgenie/ || systemdgenie

• isd — Szöveges felhasználói felülettel (TUI) rendelkező alkalmazás a systemd unit-fájlokkal történő munkához.

https://github.com/kainctl/isd || isd

Szolgáltatások futtatása a hálózati kapcsolat létrejötte után

A következő függőségeket kell belefoglalni a .service fájlba annak érdekében, hogy a szolgáltatás késleltetve legyen, mindaddig, amíg a hálózat fel nem áll:

/etc/systemd/system/foo.service

[Unit]
...
Wants=network-online.target
After=network-online.target
...

A használatban lévő hálózatkezelő alkalmazás hálózati várakozási szolgáltatását is engedélyezni kell annak érdekében, hogy a network-online.target megfelelően tükrözze a hálózat állapotát.

• Ha a NetworkManager hálózatkezelő alkalmazás van használatban, akkor a NetworkManager-wait-online.service szolgáltatást a NetworkManager.service szolgáltatással együtt kell engedélyezni. Ellenőrizze, hogy ez így van-e a systemctl is-enabled NetworkManager-wait-online.service paranccsal. Ha nincs engedélyezve, akkor újból engedélyezni kell a NetworkManager.service szolgáltatást.
• A netctl használata esetén engedélyezze a netctl-wait-online.service szolgáltatást. (Kivéve amikor netctl-auto alkalmazást használ. Részletek a FS#75836 leírásban.)
• Ha a systemd-networkd van használatban, akkor a systemd-networkd-wait-online.service szolgáltatást a systemd-networkd.service szolgáltatással együtt kell engedélyezni. Ellenőrizze, hogy ez így van-e a systemctl is-enabled systemd-networkd-wait-online.service paranccsal. Ha nincs engedélyezve, akkor újból engedélyezni kell a systemd-networkd.service szolgáltatást.

Részletesebb magyarázatokért tekintse meg a Hálózati beállítás szinkronizációs pontok című vitát.

Ha egy szolgáltatásnak DNS-lekérdezéseket kell végrehajtania, akkor azt folytatólagos sorrendben a nss-lookup.target után kell elhelyezni:

/etc/systemd/system/foo.service

[Unit]
...
Wants=network-online.target
After=network-online.target nss-lookup.target
...

Tekintse meg a systemd.special(7) § Speciális passzív rendszer unit-fájlok man súgót.

Ahhoz, hogy a nss-lookup.target fájlnak bármilyen hatása legyen, szükség van egy olyan szolgáltatásra, amely behúzza azt a Wants=nss-lookup.target segítségével, és saját magát előrébb sorolja a Before=nss-lookup.target fájllal. Ez általában a helyi DNS névfeloldók által történik.

Ellenőrizze le a következő parancs kiadásával, hogy mely aktív szolgáltatás húzza be a nss-lookup.target fájlt:

$ systemctl list-dependencies --reverse nss-lookup.target

Annak a viselkedésnek az engedélyezése, hogy a számítógépre feltelepülő unit-fájlok alapértelmezetten be legyenek bekapcsolva

Alapértelmezés szerint az Arch Linux operációs rendszer nem használja a systemd előre beállított értékeit, és a feltelepülés során nem engedélyezi a legtöbb szolgáltatást.

Amennyiben Ön azt szeretné, hogy a systemd előre beállított értékei érvényesüljenek a szoftvercsomagok számítógépre történő feltelepítésekor, akkor létre kell hoznia egy pacman automatikus műveletindító fájlt (egy hook fájlt), amely futtatja a systemctl preset vagy a systemctl preset-all parancsot, valahányszor új systemd unit-fájl kerül feltelepítésre a számítógépre. Valahogy, így:

/etc/pacman.d/hooks/40-systemd-presets.hook

[Trigger]
Operation = Install
Type = Path
Target = usr/lib/systemd/system/*.service
Target = usr/lib/systemd/system/*.timer
Target = usr/lib/systemd/system/*.socket
Target = usr/lib/systemd/system/*.slice
Target = usr/lib/systemd/system/*.path
Target = usr/lib/systemd/system/*.target

[Action]
Description = Run systemctl preset
When = PostTransaction
Depends = systemd
NeedsTargets
#Ön alternatív megoldásként futtathatja a systemd preset-all parancsot.
#Ugyanakkor vegye figyelembe, hogy ez MINDEN szolgáltatást visszaállít az alapértelmezett beállításokra,
#ami valószínűleg nem az, amit Ön szeretne,
#kivéve ha gondosan beállította az elő beállításait.
Exec = /etc/pacman.d/scripts/systemd-presets-hook

/etc/pacman.d/scripts/systemd-presets-hook

#!/bin/sh -e

while read -r f; do
    unit="${f##*/}"
    # Ön alternatív megoldás céljából beolvashatja az összes unit-fájlt, majd egyetlen futtatással átadhatja őket a systemctl preset parancsnak.
    systemctl preset "$unit"
done

Az Arch Linux tartalmazza a /usr/lib/systemd/system-preset/99-default.preset fájlt, amely fájlban megtalálható a disable * beállítás. Ez a beállítás azt eredményezi, hogy a systemctl preset alapértelmezés szerint minden unit-fájlt letilt, így amikor új szoftvercsomag kerül feltelepítésre a számítógépre, akkor a felhasználónak manuális úton, kézzel kell engedélyeznie az adott unit-fájlt.

Az unit-fájlok alapértelmezett engedélyezéséhez egyszerűen hozzon létre egy szimbolikus linket a /etc/systemd/system-preset/99-default.preset fájlból a /dev/null irányába, vagy cserélje le egy olyan fájlra, amely tartalmazza az enable * beállítást, így felülírva a beállításfájlt. Ez azt eredményezi, hogy a systemctl preset minden telepített unit-fájlt engedélyezni fog (az unit-fájl típusától függetlenül), kivéve amikor egy másik fájlban, a systemctl preset beállításkönyvtáraiban másként van megadva. A felhasználói unit-fájlokra ez nem vonatkozik. Lehetőség van magasabb prioritású fájlok létrehozására is, amelyek pontosabb szabályokat tartalmaznak arra vonatkozóan, hogy mi legyen engedélyezve. További információért tekintse meg a systemd.preset(5) man súgót.

Megjegyzés Az unit-fájlok alapértelmezett engedélyezése problémát okozhat azoknál a szoftvercsomagoknál, amelyek kettő vagy több, egymást kölcsönösen kizáró unit-fájlt tartalmaznak. A systemctl preset kifejezetten disztribúciók, változatok vagy rendszergazdák számára készült. Abban az esetben, amikor kettő ütköző unit-fájl van engedélyezve, Önnek meg kell adnia, hogy melyik unit-fájlt kell letiltani egy elő beállítási fájlban, ahogyan azt a systemd.preset(5) man súgó leírja.

Sandboxing application environments

Tekintse meg a systemd/Sandboxing című cikket.

Értesítés a meghibásodott szolgáltatásfájlokról

A szolgáltatásmeghibásodások jelzése érdekében a szóban forgó szolgáltatásfájlhoz hozzá kell adni egy OnFailure= direktívát, például egy beilleszthető kódrészletfájl beállításfájljának használatával. Ennek a direktívának minden szolgáltatás unit-fájlhoz történő hozzáadása egy felsőszintű beilleszthető kódrészletfájl beállításfájljával érhető el. A felsőszintű beilleszthető kódrészletfájlok részleteiről a systemd.unit(5) man súgóban olvashat többet.

Felsőszintű beilleszthető kódrészletfájl létrehozása szolgáltatásokhoz:

/etc/systemd/system/service.d/toplevel-override.conf

[Unit]
OnFailure=failure-notification@%n.service

A fenti művelet minden szolgáltatásfájlhoz hozzáadja az OnFailure=failure-notification@%n.service direktívát. Ha a példaszolgáltatás_unif-fájlja meghibásodik, akkor a failure-notification@példaszolgáltatás_unif-fájlja.service indul el annak érdekében, hogy kezelje az értesítés kézbesítését (vagy bármely más feladatot, amire be van állítva).

A failure-notification@.service sablon unit-fájl létrehozása:

/etc/systemd/system/failure-notification@.service

[Unit]
Description=Send a notification about a failed systemd unit

[Service]
Type=oneshot
ExecStart=/path/to/failure-notification.sh %i
# runs as a temporary user/group and enables several other security precautions
DynamicUser=true

Ön létrehozhatja a failure-notification.sh szkriptfájlt, és meghatározhatja, hogy mi történjen vagy hogyan történjen az értesítés. Példák erre az e-mail küldése, asztali értesítések megjelenítése, gotify, XMPP használata stb. A %i a meghibásodott szolgáltatás unit-fájl neve lesz, és argumentumként kerül átadásra a szkriptfájlnak.

A failure-notification@.service példányok ismétlődő elindításának megakadályozása érdekében (amennyiben az indítás sikertelen), hozzon létre egy üres beilleszthető kódrészletfájl beállításfájlját ugyanazzal a névvel, mint ami a felsőszintű beilleszthető kódrészletfájl neve. (Az üres, szolgáltatásszintű beilleszthető kódrészletfájl beállításfájlja elsőbbséget élvez a felsőszintű beilleszthető kódrészletfájllal szemben, és felülírja azt.):

# mkdir /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

Értesítés e-mail által

Be lehet állítani a systemd programot úgy, hogy e-mailt küldjön, amikor egy unit-fájl hibát jelez. A cron a MAILTO címre küld levelet, amennyiben a feladat kimenetet ad stdout vagy stderr felé, de sok feladat úgy van beállítva, hogy egyedül hiba esetén adjon kimenetet. Először kettő fájlra van szükség: Egy végrehajtható fájlra az e-mail küldése érdekében, és egy .service fájlra a végrehajtható fájl elindítása érdekében. Ebben a példában a végrehajtható fájl egy egyszerű shell szkriptfájl, amely a sendmail programot használja, ami megtalálható az smtp-forwarder programot biztosító szoftvercsomagokban.

/usr/local/bin/systemd-email

#!/bin/sh

/usr/bin/sendmail -t <<ERRMAIL
To: $1
From: systemd <root@$HOSTNAME>
Subject: $2
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8

$(systemctl status --full "$2")
ERRMAIL

Ön bármilyen végrehajtható fájlt használ, annak célszerű legalább kettő argumentumot fogadnia, ahogyan azt ez a shell szkriptfájl is teszi: A címzett címét fogadja, ahová küldeni kell a levelet, valamint az unit-fájlt fogadja, amelynek az állapotát le kell kérdezni. Az általunk létrehozott .service ezeket az argumentumokat fogja átadni:

/etc/systemd/system/status_email_user@.service

[Unit]
Description=status email for %i to user

[Service]
Type=oneshot
ExecStart=/usr/local/bin/systemd-email address %i
User=nobody
Group=systemd-journal

Ahol az user az a felhasználó, akinek e-mailt küldünk, és az address az adott felhasználó e-mail címe. Bár a címzett kódolva van, az unit-fájl, amelyről jelentést kell készíteni, példányparaméterként kerül átadásra, így ez az egyetlen szolgáltatás sok más unit-fájlhoz is tud e-mailt küldeni. Ön ezen a ponton elindíthatja a status_email_user@dbus.service szolgáltatást annak ellenőrzése érdekében, hogy meg tudja-e kapni az e-maileket.

Ezután egyszerűen szerkessze azt a szolgáltatásfájlt, amelyhez e-maileket szeretne kapni, és adja hozzá a OnFailure=status_email_user@%n.service sort az [Unit] szekcióhoz. A %n az unit-fájl nevét adja át a sablonnak.

Megjegyzés

• Amennyiben Ön az sSMTP#Security szerint állítja be az sSMTP biztonságát, akkor a nobody felhasználónak nem lesz hozzáférése a /etc/ssmtp/ssmtp.conf fájlhoz, és a systemctl start status_email_user@dbus.service parancs sikertelen lesz. Az egyik megoldás az, hogy a status_email_user@.service unit-fájlban felhasználóként a root van megadva.
• Amennyiben Ön megpróbálja használni a mail -s somelogs address parancsot az e-mail szkriptfájlban, a mail folyamat el fog ágazódni, és a systemd leállítja a mail folyamatot, amikor érzékeli, hogy a szkriptfájl futása befejeződött. A következő módon állítsa be úgy a mail folyamatot, hogy ne tudjon elágazni: mail -Ssendwait -s somelogs address.

Tipp Az újabb systemd verziók azt javasolják, hogy az User=nobody helyett használja a DynamicUser=true beállítást, mivel az előbbi beállítás már nem ajánlott. További részletekért tekintse meg a GitHub 428 hibával kapcsolatos bejegyzést.

Számítógép kikapcsolásakor a külső HDD automatikus kikapcsolása

Tekintse meg az udisks#Automatically turn off an external HDD at shutdown című leírást.

Hibaelhárítás

Sikertelen szolgáltatások vizsgálata

A következő paranccsal azokat a szolgáltatásokat lehet kilistázni amelyek nem indultak el a systemd alatt:

$ systemctl --failed

A hiba okozójának a kiderítése érdekében vizsgálja meg a napló kimenetét. Részletek a systemd/Journal#Kimenet szűrése című leírásban.

Tipp

Lehetőség van az unit-fájlok "failed" állapotának a törlésére, így eltávolítva őket a systemctl --failed kimenetéből:

# systemctl reset-failed unit

Vegye figyelembe, hogy a fenti parancs általában eltávolítja az unit-fájlt a számítógép memóriájából, ami miatt a systemctl status többé nem jelzi a hibás állapotot, illetve a naplókat. (Részletek a systemd.unit(5) man súgóban a CollectMode leírásnál).

Bootolási problémák diagnosztizálása

A systemd a bootolási folyamat problémáinak diagnosztizálására számos lehetőséget kínál. Általános útmutatásokért és az bootolási üzenetek rögzítésének lehetőségeiért, mielőtt a systemd átvenné az bootolási folyamat irányítását, tekintse meg a bootolási hibakeresés című cikket. Továbbá, tekintse meg a systemd hibakeresési dokumentációját.

Szolgáltatás diagnosztizálása

Ha valamelyik systemd szolgáltatás nem működik megfelelően, vagy Ön több információt szeretne kapni arról, hogy mi történik, akkor állítsa be a SYSTEMD_LOG_LEVEL környezeti változót debug értékre. A lenti példa a systemd-networkd szolgáltatás futtatását mutatja be hibakeresési módban.

Adjon hozzá egy beilleszthető kódrészletfájlt a szolgáltatáshoz. A beilleszthető kódrészletfájl a következő kettő sort tartalmazza:

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

Illetve, ennek megfelelően, manuális úton, kézzel állítsa be a környezeti változót:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

Végül, indítsa újra a systemd-networkd szolgáltatást, és figyelje a naplót a szolgáltatáshoz tartozó -f/--follow kapcsolóval.

Rettenetesen sokáig tart a számítógép leállítása/újraindítása

Ha a számítógép leállításának folyamata nagyon sokáig tart (vagy úgy tűnik, hogy lefagy a folyamat), akkor nagy valószínűséggel egy szolgáltatás nem fejeződik be, és ez okozza a problémát. A systemd minden szolgáltatásnál vár egy ideig, mielőtt megpróbálja azt leállítani. Annak megállapítása érdekében, hogy Ön érintett-e a nem befejeződést illetően, tekintse meg a systemd dokumentációban található Shutdown completes eventually című részt.

Egyik gyakori probléma szokott lenni a számítógép leállítás elakadása vagy a felfüggesztés elakadása. Annak ellenőrzésére, hogy ez a helyzet áll-e fenn, futtassa az alábbi parancsok egyikét, és vizsgálja meg a kimenetet:

# systemctl poweroff

Failed to power off system via logind: There's already a shutdown or sleep operation in progress

# systemctl list-jobs

  JOB UNIT                    TYPE  STATE
...
21593 systemd-suspend.service start running
21592 suspend.target          start waiting
..

A megoldás erre a problémára az lenne, hogy Ön ezeket a feladatokat megszakítja az alábbi parancs futtatásával:

# systemctl cancel
# systemctl stop systemd-suspend.service

A megszakítás után próbálja meg ismét a számítógép leállítását vagy az újraindítását.

Úgy tűnik, hogy a rövid életű folyamatok nem naplóznak semmilyen kimenetet

Amennyiben Ön root felhasználói jogosultsággal futtatja a journalctl -u példaunit parancsot, és a parancs nem mutat semmilyen kimenetet egy rövid életű szolgáltatásnál, akkor inkább a PID azonosítót nézze meg. Például, amikor a systemd-modules-load.service hibát jelez, és a systemctl status systemd-modules-load azt mutatja, hogy PID 123 alatt futott, akkor előfordulhat, hogy látja a kimenetet a naplóban ennél a PID-nél, azaz root felhasználói jogosultsággal futtatva a journalctl -b _PID=123 parancsot. A napló metaadat-mezői, mint például _SYSTEMD_UNIT és _COMM, aszinkron módon kerülnek összegyűjtésre, és a /proc könyvtárra támaszkodnak a folyamat létezéséhez. Ennek javítása a kernel javítását igényli annak érdekében, hogy ezeket az adatokat socket kapcsolaton keresztül biztosítsa, hasonlóan az SCM_CREDENTIALS mechanizmus. Röviden, ez egy hiba. Ne feledje, hogy azonnal meghiúsult szolgáltatások a systemd tervezése szerint lehet, hogy nem írnak semmit a naplóba.

Fokozatosan növekszik a bootolási idő

A systemd-analyze használata után több felhasználó észrevette, hogy a bootolási idejük jelentősen megnőtt ahhoz képest, amilyen korábban volt. A systemd-analyze blame használata után a NetworkManager szokatlanul hosszú időt vesz igénybe az induláshoz.

Néhány felhasználónál a probléma abból adódott, hogy a /var/log/journal túl nagyra nőtt. A megnövekedett journal más teljesítménybeli hatásokkal is járhat, például a systemctl status vagy a journalctl esetében. A megoldás tehát az, hogy Ön töröl minden fájlt a könyvtárból (ideális esetben készítve róla biztonsági mentést valahová, legalább ideiglenesen), majd beállít egy naplófájl méretkorlátot a systemd/Journal#Journal méretlimit című leírásnak megfelelően.

Nem indul el bootoláskor a systemd-tmpfiles-setup.service

A systemd 219 verziójától kezdve a /usr/lib/tmpfiles.d/systemd.conf ACL attribútumokat határoz meg a /var/log/journal alatti könyvtárakhoz, és ezért szükséges, hogy az ACL támogatás engedélyezve legyen azon a fájlrendszeren, ahol a napló található.

Az /var/log/journal könyvtárat tartalmazó fájlrendszeren az ACL engedélyezésének módjával kapcsolatban tekintse meg a Access Control Lists#Enable ACL című leírást.

Vészhelyzeti mód letiltása távoli számítógépen

Előfordulhat, hogy Ön le szeretné tiltani a vészhelyzeti módot egy távoli számítógépen (például egy Azure vagy Google Cloud által hosztolt virtuális számítógépen). A letiltás oka az, hogy amikor a vészhelyzeti mód aktiválódik, akkor a számítógép nem tud csatlakozni a hálózathoz.

A letiltás érdekében a mask parancsot kell alkalmazni a emergency.service és a emergency.target unit-fájlokra.

Létezik a szolgáltatás, de én mégis az "Unit xxx.service not found" hibát kapom

Előfordulhat az, hogy Ön egy user unit-fájlt próbál elindítani vagy engedélyezni próbálja az user unit-fájlt rendszerszintű unit-fájlként. A systemd.unit(5) jelzi, hogy mely unit-fájlok hol találhatók. Alapértelmezés szerint a systemctl rendszerszintű szolgáltatásokon működik.

További részletekért tekintse meg a systemd/User című leírást.

EFI partíció UUID azonosítójának megváltoztatása után a LoaderDevicePartUUID manuális úton történő megújítása

Néhány boot loader program egyedül akkor állítja be a LoaderDevicePartUUID változót amikor a változó üres. Következésképpen, még ha az EFI partíció UUID azonosítója meg is változik, a boot loader program akkor se nem frissíti a LoaderDevicePartUUID értékét. Az EFI változó törlésével, az alábbi parancsok segítségével, a boot loader program újra feltölti a változót az új UUID azonosítóval.

# chattr -i /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
# rm /sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f

További olvasnivaló a témában

• Wikipedia:systemd
• Official web site
  • systemd optimizations
  • systemd FAQ
  • systemd Tips and tricks
• systemd(1)
• Other distributions
  • Gentoo:systemd
  • Fedora:systemd
  • Fedora:How to debug Systemd problems
  • Fedora:SysVinit to Systemd Cheatsheet
  • Debian:systemd
• Lennart's blog story, update 1, update 2, update 3, summary
• Debug Systemd Services
• systemd for Administrators (PDF)
• How To Use Systemctl to Manage Systemd Services and Units
• Session management with systemd-logind
• Emacs#Syntax highlighting for systemd files
• Two part introductory article in The H Open magazine.