systemd (Magyar) - ArchWiki

Jump to content

# systemd (Magyar)

From ArchWiki
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.

További oldalak az adott témakörben

- 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

This article or section needs expansion.

Reason: Ha meg van adva az `--runtime`, akkor a változtatások ideiglenesen a `/run/` könyvtárban lesznek végrehajtva, és a következő számítógép újraindításakor elvesznek. Példa lehet hibakeresési jelölőzászlók átadása egy szolgáltatásnak úgy, hogy ne kívánja a változtatásokat véglegesen megtartani. (Discuss in Talk:Systemd (Magyar))

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

The factual accuracy of this article or section is disputed.

Reason: Ez az oldal a PID 1 (init) folyamatról szól, és a unit-fájlokhoz tartozó beilleszthető kódrészletek már említésre kerültek. A beilleszthető kódrészletek egy általános fogalom, ráadásul más systemd komponenseknek megvan a saját wiki oldaluk. Ezért úgy tűnik, hogy ez a szakasz nem ide tartozik. (Discuss in Talk:Systemd (Magyar)#YHNdnzj : Beállításfájlok a conf.d / beilleszthető kódrészletek töredékekben: Talán rossz helyen van.)

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

This article or section needs expansion.

Reason: Hogyan működik a példányosított unit-fájlok esetében? (Discuss in Talk:Systemd (Magyar))

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ő

The factual accuracy of this article or section is disputed.

Reason: A NetworkManager problémák nem a systemd hibája. Az állítólagos jelentések hiányoznak. A lassú `systemctl status` vagy `journalctl` nem befolyásolja a bootolási időt. (Discuss in Talk:Systemd (Magyar))

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.

Category:

- Init (Magyar)

Hidden categories:

- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Accuracy

systemd (Magyar)
Add topic