udev & D-Bus & HAL helyett DeviceKit helyett udisks+UPower - 4. rész: systemd

A systemd célja nem csak /sbin/init, és a System V init rendszer központi vezérlőszkriptjének leváltása, hanem magukat az init szkripteket is ki akarják váltani. Ennek több oka van:
- Az init szkriptek futtatásához interpreter (többnyire UNIX shell) szükséges, ami a boot-folyamatban szerephez jutó többszáz szkript esetében hatalmas felesleges CPU, I/O és memóriaterhelést okoz.
- Az init szkriptek felépítése nehezen szabványosítható, még a különböző Linux-disztribúciók között is nagyok lehetnek a különbségek ilyen szempontból. A szkriptek funkcióját a systemd viszonylag egyszerű konfigurációs fájlok által vezérelve tölti be.

Alapvetően kétféle initszkriptről beszélhetünk a boot-folyamat kapcsán. Az első típusba a korai fázisban aktivizálódó, (többnyire) a disztribútor által kifejlesztett, rendszerközeli, GNU/Linux-, sőt disztribúcióspecifikus szkriptek tartoznak. Ezek értelmezik a leginkább rendszerközeli konfigfájlokat, pl. a /etc/sysconfig könyvtárban levőket, az /etc/fstab-ot, stb. Ezen szkripttípus kiváltásának érdekében a systemd fejlesztői arra biztatják a Linux disztribútorokat, hogy a saját fejlesztésű rendszerszkriptjeiket és azok konfigurációs adatbázisait vonják ki a forgalomból, és helyette a systemd által biztosított egységes megoldásokra alapozzanak. Mivel még a systemd ilyen irányú képességei sem teljeskörűek, ennek az átállási folyamatnak a célba érése csak a viszonylag távoli jövőben várható (sőt, még el sem kezdődött igazából). Az initszkriptek második fő típusába a nehézsúlyú, többféle UNIX-variánson futó, sokszor 3rd party szoftvernek minősülő rendszerek (pl. levelezőrendszerek, webszerverek, fájlszerverek, adatbázisszerverek, stb.) indítószkriptjei tartoznak. Az ilyen, többféle UNIX-on futó démonok initszkriptjeit sokszor nem a disztribúció, hanem magának a 3rd party szoftvernek a fejlesztői írják, vagyis a démonnal együtt érkezik. Mivel az initszkripteket nem mindig az init rendszer futtatja, hanem előállhat pl. olyan eset is, hogy a rendszergazda maga indítja vagy állítja le parancssorból a szolgáltatásokat, a démonoknak trükkök százaihoz kell folyamodniuk, hogy függetlenítsék magukat attól a környezettől, amiben elindították őket, pl. a leválás a (virtuális) konzolról, új processz session indítása, double fork művelet végrehajtása, annak érdekében, hogy a processzfában közvetlenül az 1-es PID (init) alá helyezze át őket a kernel, stb. A démonok az esetek túlnyomó részében root-ként indulnak (mert a root felhasználó indítja őket), de sok esetben eldobják a jogosultságaik egy részét, hogy ne jelentsenek biztonsági kockázatot az oprendszerre nézve. Miután a systemd az ilyen 3rd party initszkripteket is le szeretné váltani idővel, a fejlesztői arra buzdítják a démon programok íróit, hogy ezeket a kezdeti inicializációs lépéseket (leválasztódás, double fork, jogosultságeldobás, stb.) ne maguk végezzék, hanem hagyatkozzanak a systemd-re minden szempontból. A systemd többek között még a démonok naplózási üzeneteinek syslog felé történő továbbítását is magára vállalná, ezért elegendő, ha a démonok egyszerűen a stdout-ra logolnak. A démonokkal kapcsolatos hagyományos és új, systemd-korabeli igények közötti különbséget jól szemlélteti a man 7 daemon oldal.

Az 1-es PID-del futó processz legfőbb különlegessége a UNIX rendszereknél egyébként nem is az, hogy az oprendszer bootolását és levezénylik, hanem az, hogy azokat a futó processzeket, amelyeknek a szülő processze "meghal", a kernel az öröklési fában áthelyezi alá, mintha az 1-es processz lenne a szülőjük. Ezzel a kernel azt a feladatot rója az init processzre, hogy a hozzárendelt gyermekprocesszek állapotát olvassa ki a wait rendszerhívással miután meghaltak, mert amíg ezt nem teszi meg, a kernel kénytelen fenntartani egy adatstruktúrát a már halott processz számára. Az ilyen halott, de wait rendszerhívással még le nem "aratott" processzeket zombi processznek hívjuk. A systemd természetesen betölti a korábban az init által végzett aratási feladatot, mert ha nem tenné, az elszaporodó zombi processzek kernelbeli adatstruktúrái szélsőséges esetben a memória elfogyásához is vezethetnének.

Amint a sorozat második részében említettem, a systemd systemd-loginctl szolgáltatása átveszi a ConsoleKit szerepét oly módon, hogy a Linux-specifikus control group-okat felhasználva csoportosítja a processzeket. Nem csak a felhasználói munkamenetek processzeit csoportosítja azonban a control groupok segítségével, hanem a rendszerszolgáltatások processzeit is, ezáltal a UNIX történetében először(?) lehetővé válik, hogy egy adott szolgáltatás leállításakor leállítsuk a véletlen double fork vagy más hiba folytán az adott szolgáltatás processzfájából kiszakadt, ezért beazonosíthatatlan processzeket is.

A systemd nem csak a rendszerszolgáltatások és felhasználói munkamenetek kezelését képes elvégezni, hanem más erőforrásokét is, pl. a fájlrendszerekét, ami által hosszútávon akár a /etc/fstab teljes leváltása is bekövetkezhet. A sokféle rendszererőforrás menedzselését ráadásul úgy képzelik el hosszú távon a systemd fejlesztői, hogy azok mind egyszerre, egy időben aktiválódjanak a boot-folyamat során! Az indulást tehát nem meghatározott sorrend szerint, hanem eseményvezérelten tervezik végrehajtani. Az eseményvezérlést az inetd szuperszerver mintájára valósítják meg, de amíg az inetd csak TCP/UDP socketeken hallgatózva tudja aktiválni a szolgáltatásait, a systemd ezt más kommunikációs csatornákra is kiterjeszti, pl. a UNIX domain socketekre, sőt magasabb szinten a D-Bus-ra is. Ráadásul nem csak processzek indítását, hanem akár fájlrendszerek mountolását is el tudja végezni igény szerint, mégpedig a Linux autofs/automount segítségével. Azáltal, hogy a systemd az inetd mintájára mintegy proxyként beáll az szerverdémonok és klienseik közé, sőt pufferelni is hajlandó az általa kezelt socketek forgalmát, lehetővé válik, hogy a nem állapottartó vagy az állapotukat egy újraindítás során átmenteni képes szolgáltatásokat nyújtó programcsomagokat frissítsük (és közben újraindítsuk) anélkül, hogy ez a klienseik működésében fennakadást okozna.

A systemd a teljes rendszerkonfiguráció szabványosításának ígéretével és az agresszív, eseményvezérelt párhuzamosításokkal rendkívül ambiciózus projektnek számít. Hasonló irányba indult el, mint az Ubuntu upstart rendszere, de még annál is radikálisabb, viszont annak ellenére, hogy messzebb jutott a kiindulóponttól, az upstarttal ellentétben mégis visszamenőleges kompatibilitást biztosít a System V init rendszerrel, tehát egyértelműen jobb választásnak tűnik. Valószínű, hogy idővel az Ubuntu is beépíti a saját operációs rendszerébe. Az egyszerű UNIX /sbin/init kiváltására egyébként már több próbálkozás is született az idők folyamán, mint pl. az Apple launchd rendszere, amelyhez a systemd fejlesztői legszívesebben hasonlítják a saját megoldásukat.

A szolgáltatásokat párhuzamosan indító alternatív init rendszerekkel kapcsolatos leggyakoribb sztereotípia, hogy legfontosabb előnyük a boot-folyamat gyorsítása. Lennart Poettering és csapata méréseket végzett ezzel kapcsolatban, és arra a következtetésre jutottak, hogy az elterjedt mechanikus merevlemezekkel csak elhanyagolható mértékű gyorsulást lehet elérni a hagyományos System V init rendszerhez képest. Ennek egyik oka, hogy részben kompatibilis módban tesztelték, vagyis hagyományos System V init szkripteket hajtattak végre vele, nem pedig tisztán újfajta, natív systemd szolgáltatásokat. A másik ok (ami nagyrészt az elsőből következik, de inkább csak a HDD-ket érinti) az volt, hogy a boot-folyamat során rengeteg shell-szkript fut le, amelyek rengeteg konfigurációs fájlt olvasnak be, tehát hatalmas, véletlenszerű olvasási terhelést jelentenek az I/O alrendszernek, amivel a mechanikus merevlemezek sokkal kevésbé képesek megbirkózni, mint az SSD eszközök.

A systemd projektet a freedesktop.org gondozza, és amint láttuk, egyre jobban integrálódik az Udev/D-Bus rendszerekkel, sőt előfordulhat, hogy azok egy idő után működésképtelenek lesznek a systemd nélkül. A systemd erőteljesen támaszkodik több Linux-specifikus szolgáltatásra (pl. control group-ok, autofs/automount), és amint Lennart Poettering youtube-os előadásából kiderül, nem is törekednek a systemd hordozhatóvá tételére, mert gyakorlatilag a Linuxot tartják az egyetlen életképes szabad operációs rendszernek. Ha ez az integráció tovább mélyül, elképzelhető, hogy a D-Bus-ra nagy mértékben alapozó asztali környezetek (pl. KDE, Gnome) nem, vagy csak csökkent funkcionalitással futnak majd a nem Linux kernelre épülő operációs rendszereken.

A sorozat részei: 1 2 3 4