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.
- nice blogja
- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Hát nem azt mondtad (írtad), hogy vége?
Köszi és subscribe erre is (tudom, most már össze vannak linkelve; tekintsük megszokásnak).
- A hozzászóláshoz be kell jelentkezni
Ez a rész még hátravolt :-)
- A hozzászóláshoz be kell jelentkezni
Köszönöm a cikket.
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.
Hát ez ütött. Végigolvastam a daemon(7)-et, ahogy azt LP elképzeli. Rémületes. A Java filozófiájának új megtestesülése: 100% damage control. Mellette pedig Linux lock-in (a forrás nyíltsága teljesen mellékes ebből a szempontból). Óda a hordozhatatlansághoz, a POSIX arcon köpése, a UNIX háborúk visszatérése. Megértük azt a napot, amikor egy Linux rendszerfejlesztő Apple irányelvekkel támasztja alá a mondandóját. Egy ezerkarú polip, amely maga köré akarja felépíteni az egész rendszert. Hiszen még az inetd is rossz ötlet volt, amíg volt!
Nagyon jól látszik a termékfejlesztési orientáció, a monokultúrára törekvés, a független fejlesztők gátlástalan noszogatása az illeszkedésre. Az arrogancia vérlázító.
Munkaidőben hajlandó lennék illeszkedő daemon-t fejleszteni.
Ha kifut alólam az utolsó, rendesen támogatott Linux disztró is, amelyben nincs systemd, másik OS-t fogok keresni. FreeBSD, here I come?...
- A hozzászóláshoz be kell jelentkezni
Hát igen, a helyzet súlyosnak tűnik. Úgy tudom, a HAL és a ConsoleKit annak idején hordozható volt, de úgy tűnik, az új technológiák idővel lehetetlenné teszik a desktop rendszerek használatát *BSD és *Solaris környezetekben. El tudom képzelni, hogy vannak kulcsfontosságú szabad szoftver projektek, amelyek elsődlegesen BDS-n dolgoznak, úgyhogy a freedesktop.org-osok fafejűsége akár meg is bosszulhatja magát....
- A hozzászóláshoz be kell jelentkezni
Szerintem jo lenne ezt a sorozatot bekuldeni cikk formajaban, hogy konnyebben keresheto legyen, es hogy megmaradjon az utokornak.
- A hozzászóláshoz be kell jelentkezni
Újra átolvastam egyben a 4 részt, csak hálálkodni tudok. Ennek a területnek a feltérképezése rég fenn volt a todo listámon mint fakultatív feladat, de annyira jól és következetesen felépített magyarázatot adtál mindenre, hogy simán kihúzhatom, megspórolva ezzel pár napot. Köszönöm!
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
kapcsolodik: http://www.change.org/petitions/lennart-poettering-stop-writing-useless…
amugy tenyleg jo leirasok, en is koszonom
- A hozzászóláshoz be kell jelentkezni
Ajaj, ez a bináris logolás tényleg félelmetes. Az az igazság, a systemd esetében ennyire nem másztam bele a részletekbe, inkább csak a lényeget akartam megérteni.
- A hozzászóláshoz be kell jelentkezni
a leirasod alapjan viszont "a lenyeg" picit majdnem meg is nyugtatott, ugy tunt, mintha esszel terveztek volna igy hirtelen :D
de a legkemenyebb az a fejleszto indoklasa volt: "ha olyan betores lesz mint a kernel org pwn idejen, akkor nehezebb lesz modositani a logokat, ha binarisak" ( http://lwn.net/Articles/468049/ )
de tegyuk fel, hogy tenyleg szukseg van erre a binaris logolasra: akkor is az lenne a normalis, hogy tud binarisan es nembinarisan is logolni (es hogy default a nembinaris, aki "mindenre gondol", majd binarissa teszi maganak)
- A hozzászóláshoz be kell jelentkezni
olvasmányos a témával kapcsolatban
http://0pointer.de/blog/projects/the-biggest-myths
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
+1
Sic Transit Gloria Mundi
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
És Bámm... mindenre is van a systemd...
- A hozzászóláshoz be kell jelentkezni