8.7 Szolgáltatások és rendszerindítás

Amikor bekapcsolod a számítógépedet, és a fekete képernyőn átvillanó szövegek után megjelenik a grafikus bejelentkező felület, a háttérben egy lenyűgözően komplex, mégis szigorúan szabályozott gépezet dolgozik. A modern Linux disztribúciók lelke és karmestere egy systemd nevű rendszer- és szolgáltatáskezelő szoftver.

A systemd felelős azért, hogy a rendszerindítás (boot) során a megfelelő sorrendben induljanak el a hálózati kártyák, a Bluetooth, a webszerverek vagy az SSH-kapcsolatok. Továbbá ez a rendszer gyűjti össze az összes futó program hibaüzenetét egyetlen központosított naplóba.

Ebben a fejezetben megtanuljuk, hogyan veheted át az irányítást a háttérben futó folyamatok (szolgáltatások vagy démonok) felett a systemctl paranccsal, és hogyan derítheted ki a journalctl segítségével, hogy miért nem indul el egy program.

8.7.1 A boot folyamat megértése (A PID 1)

Mielőtt parancsokat osztogatnánk, fontos megérteni, mi is történik a bekapcsológomb megnyomásától a használható rendszerig. A folyamat négy fő lépésre bontható:

1. BIOS / UEFI: A hardver inicializálása. Az alaplap ellenőrzi a memóriát, a processzort, és megkeresi az indítható meghajtót.
2. Bootloader (általában a GRUB): Ez a kis menü, ahol kiválaszthatod, melyik operációs rendszert vagy kernelt szeretnéd indítani. A GRUB betölti a memóriába a Linux magját.
3. Kernel (a rendszermag): A kernel átveszi az irányítást a hardver felett. Felismeri a videókártyát, a merevlemezeket, és létrehozza az alapvető memóriakezelést.
4. Az Init rendszer (systemd): A kernel utolsó lépésként elindítja a legelső programot. Ez a program kapja meg a PID 1 (Process ID 1) azonosítót. A modern rendszereken ez a systemd.

Mivel a systemd a PID 1, minden más program az ő leszármazottja. Ő indítja el a grafikus felületet, a hálózatkezelőt és a terminált is. Ha a systemd összeomlik, az egész operációs rendszer leáll.

8.7.2 Szolgáltatások kezelése: systemctl

A háttérben folyamatosan futó programokat a Linux világában démonoknak (daemons) vagy szolgáltatásoknak hívjuk. Nevük általában egy d betűre végződik (pl. az SSH szerver neve sshd, de a hálózatkezelőé NetworkManager.service, a nyomtatásvezérlő cups.service).

Ezeknek a szolgáltatásoknak a vezérlésére szolgál a systemctl parancs. Mivel a szolgáltatások leállítása vagy elindítása rendszerszintű módosítás, a legtöbb parancs kiadásához rendszergazdai (sudo) jogosultság szükséges.

A parancs felépítése szinte mindig ugyanaz: sudo systemctl [utasítás] [szolgáltatás_neve]

1. Állapotlekérdezés (status)

A legbiztonságosabb és leginformatívabb parancs. Megmutatja, hogy egy szolgáltatás fut-e, mikor indult, és mik voltak az utolsó naplóüzenetei. Ezt sudo nélkül is futtathatod:

systemctl status sshd

A kimenetben keresd az Active: sort. Ha zölddel azt látod, hogy active (running), a szolgáltatás tökéletesen működik. Ha pirossal az failed felirat fogad, valami hiba történt. (A hosszú listából a q billentyű megnyomásával tudsz kilépni).

2. Kézi indítás és leállítás (start / stop)

Ha egy szolgáltatás nem fut, vagy ideiglenesen le akarod állítani:

• Indítás: sudo systemctl start sshd

• Leállítás: sudo systemctl stop sshd

3. Újraindítás és konfiguráció-frissítés (restart / reload)

Ha módosítottad egy futó program beállításait (például átírtad egy webszerver konfigurációs fájlját), a program nem fogja magától észrevenni a változást. Ilyenkor két lehetőséged van:

• Restart: Kíméletlenül kilövi a szolgáltatást, majd újraindítja. Minden aktív kapcsolat megszakad.

sudo systemctl restart sshd

• Reload: Sokkal elegánsabb módszer. A program tovább fut, a kapcsolatok nem szakadnak meg, de a szoftver a háttérben újraolvassa a beállítási fájljait. (Nem minden szolgáltatás támogatja).

sudo systemctl reload nginx

4. Automatikus indítás bootoláskor (enable / disable)

A start parancs csak az aktuális munkamenetre vonatkozik. Ha újraindítod a gépet, a szolgáltatás ismét inaktív lesz. Ha azt szeretnéd, hogy egy program a géppel együtt, automatikusan elinduljon a háttérben, engedélyezned kell:

• Engedélyezés (automatikus indulás bekapcsolása):

sudo systemctl enable sshd

• Tiltás (automatikus indulás kikapcsolása):

sudo systemctl disable sshd

Profi tipp: A modern systemctl ismeri az --now kapcsolót. Ha egy szolgáltatást engedélyezni is akarsz a jövőre nézve, és azonnal el is akarod indítani, nem kell két külön parancsot kiadnod. Elég ennyi: sudo systemctl enable --now sshd

8.7.3 Logok valós idejű figyelése: journalctl

A régi Linux rendszereken, ha egy program hibát dobott, a rendszergazdának végig kellett bújnia a /var/log könyvtár tucatnyi különböző, eltérő formátumú szövegfájlját (syslog, auth.log, dmesg, stb.).

A systemd ezt a káoszt is megszüntette. A hozzá tartozó journald szolgáltatás minden rendszer- és programüzenetet egyetlen, bináris, indexelt és titkosítható adatbázisba gyűjt. Ebből az adatbázisból a journalctl paranccsal tudsz hihetetlenül precízen keresni.

1. A teljes napló olvasása

Ha paraméterek nélkül adod ki a parancsot, megkapod a rendszer legrégebbi rögzített üzenetétől kezdve az összes logot. Mivel ez több millió sor is lehet, érdemes felkészülni a navigációra (az olvasó felület ugyanaz, mint a less parancsnál: nyilakkal mozogsz, q-val lépsz ki).

journalctl

2. Csak a mai, vagy az utolsó bootolás óta történt események

Általában nem vagyunk kíváncsiak a hetekkel ezelőtti logokra. A -b (boot) kapcsolóval csak az aktuális rendszerindítás óta keletkezett naplókat kérdezed le:

journalctl -b

3. Egy konkrét szolgáltatás hibáinak keresése

Ha kiadod a systemctl status nginx parancsot, és azt látod, hogy a webszerver összeomlott (failed), a leggyorsabban a -u (unit) kapcsolóval derítheted ki az okot. Ez kiszűri az összes naplóból csak azt, amit a megadott program generált:

journalctl -u nginx

4. Szűrés idő és súlyosság alapján

A journalctl érti az emberi időmeghatározásokat. A --since kapcsolóval megadhatsz konkrét időpontokat:

journalctl --since "1 hour ago"

journalctl --since "2026-06-29 08:00:00"

Ha csak a kritikus hibákra (Error) vagy kíváncsi, a figyelmeztetésekre (Warning) és információs üzenetekre (Info) nem, használd a -p err (priority) kapcsolót:

journalctl -p err -b

(Ez a parancs kilistázza az aktuális bootolás óta történt összes piros, kritikus hibát a rendszerben).

5. Logok élő, valós idejű követése (A Mátrix nézet)

Az egyik leghasznosabb funkció a hibakeresésnél a -f (follow) kapcsoló. Ha ezt kiadod, a terminál nem tér vissza a parancssorhoz. Rácsatlakozik az élő naplófolyamra, és amint a rendszerben keletkezik egy új üzenet, az azonnal megjelenik a képernyődön.

journalctl -f

Tökéletes megoldás, amikor elindítasz egy hibásnak vélt szolgáltatást egy másik terminálablakban, és itt azonnal, élőben látod, hol akad el a folyamat. A kilépéshez itt is a Ctrl + C billentyűket használd.

Fun Fact: A systemd mint főellenség

A Linux-közösség híres arról, hogy árgus szemekkel figyeli a nyílt forráskódú projektek forráskód-módosításait, különösen, ha az a mindent irányító systemd-t érinti. 2024 nyarán egy ártatlannak tűnő kódmódosítás valóságos összeesküvés-elméleti hullámot indított el, aminek a középpontjában a kötelező online életkor-ellenőrzés (age verification) állt.

A botrány akkor robbant ki, amikor a fejlesztők bemutatták a systemd-vpick nevű új komponenst. Ennek az eszköznek a feladata elvileg pofonegyszerű: segít a rendszernek kiválasztani a legfrissebb és leginkább megfelelő verziójú lemezképeket vagy fájlokat egy adott könyvtárból.

A paranoiát azonban a kódhoz mellékelt hivatalos dokumentáció egyik példája indította el. A fejlesztők szemléltetésképpen egy olyan fiktív forgatókönyvet írtak le, amelyben a rendszer ellenőrzi, hogy egy felhasználó elmúlt-e 18 éves, mielőtt hozzáférést biztosítana bizonyos tartalmakhoz.

Mivel ebben az időszakban az Egyesült Államokban és Európában is terítéken voltak a felnőtt tartalmú oldalak kötelező életkor-ellenőrzését előíró törvénytervezetek, a felhasználók azonnal összekötötték a pontokat. Sokan meggyanúsították a systemd atyját, Lennart Poetteringet és a mögötte álló fejlesztőgárdát, hogy titokban a kormányok megrendelésére építik be a cenzúra és a digitális személyazonosság-ellenőrzés alapjait közvetlenül a Linux operációs rendszer magjába.

A valóságban szó sem volt kormányzati összeesküvésről. A fejlesztők csupán egy szerencsétlen, de életszerűnek szánt példát használtak arra, hogyan lehet feltételes logikát (például dátumok összehasonlítását) kezelni az új verzióválasztó kóddal. A felháborodás láttán a systemd csapata gyorsan törölte is a vitatott részt a dokumentációból, de a bizalmatlan felhasználóknál ez már olaj volt a tűzre: a systemd-t amúgy is sokan kritizálják azért, mert túl nagyra nőtt, túl sok feladatot kebelezetett be (monolitikus), és eltávolodik a klasszikus, minimalista Unix-filozófiától.

Systemd alternatívák

Az aggódó vagy a systemd komplexitását elutasító felhasználók és rendszergazdák körében ekkor ismét reflektorfénybe kerültek azok a disztribúciók és init rendszerek, amelyek garantáltan „systemd-mentesek” (systemd-free). Ha valaki teljesen ki akarja hagyni a systemd-t a boot folyamatból, a következő alternatívák után néz:

• OpenRC: A legnépszerűbb és legstabilabb systemd-alternatíva. Unix-hű, shell szkriptekre épül, hihetetlenül gyors, és alapértelmezetten olyan rendszerek használják, mint a Gentoo vagy az Artix Linux.
• runit: Egy ultrakönnyű, minimalista init rendszer, amely mindössze néhány parancsból áll. Gyorsaságáról és egyszerűségéről ismert, a parancssor-orientált Void Linux alapértelmezett motorja.
• sysvinit: A klasszikus, tradicionális Init rendszer, amely évtizedeken át dominálta a Linux világát a systemd 2010-es évekbeli térnyerése előtt. Ma már leginkább a nosztalgiából vagy elvből systemd-mentesített Devuan disztribúció (a Debian systemd-mentes ága) tartja életben.

Ebből is láthatod, hogy a Linux-világban egyetlen sornyi félreérthető dokumentáció is elég ahhoz, hogy a felhasználók fellázadjanak a centralizált kontroll ellen, és alternatív utakat keressenek a rendszerük feletti teljes uralom megőrzésére.