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.
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 lettek
1
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ése
2
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ése
3
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ítani
4
systemctl mask
unit
mint root felhasználó
Egy unit-fájl
kimaszkolásának visszavonása
systemctl unmask
unit
mint root felhasználó
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.
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).
Például, amikor az
[Install]
szekciója megváltozott amióta az utoljára engedélyezve volt.
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.
A
systemctl
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:
Kernelparaméter, ahogy fent látható.
A
/etc/systemd/system/default.target
fájl szimbolikus linkje.
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.