Linux init – systemd vs sysvinit


Dnešný blog bude o porovnaní init systémov SysVinit (Sys 5 init) a systemd.

Vzhľadom k tomu, že v novej verzií Linux MINT 18.x už nie je SysVinit ale systemd, má význam poznať aspoň základné rozdiely a aj rozdielne príkazy v bashi.

systemd-vs-sysVinit-cheatsheet.jpg

Obr. porovnanie príkazov medzi SysVinit a systemd ZDROJ: linoxide

Pre bežného užívateľa je rozdiel v nich nepodstatný. Takíto užívateľ sa s danou súčasťou väčšinou nestretne.

Vopred upozorňujem, že nie je jeho cieľom vyvolať flamewar a budem pod blogom mazať príspevky, ktoré sa o to budú snažiť a to podľa môjho uváženia.
Na firemnom desktope a testovacom notebooku prevádzkujem Linux MINT 18.1 Mate ktorý už má systemd. Na desktope pri kancelárskej činnosti a práci s účtovným programom a aplikáciou eSlovensko sa nedejú žiadne zvláštne ani zložité veci.
Na testovacom notebooku nefungujú niektoré veci a je problém s power managementom.
Na svojom pracovnom počítači a notebooku mám Linux MINT 17.3 Mate bez systemd.

init_vs_systemd-300x290

Obr. Porovnanie SysVinit a systemd z pohľadu služieb a funkčnosti.

Pre začiatok najčastejšie vyzdvihované pozitíva jednotlivých systémov:

SysVinit:
* manažuje iba init systému
* spoľahlivý, otestovaný a zaužívaný v ekosystéme Linuxu a jeho integrácia je dlhodobo overená
* pracuje na všetkých architektúrach a kerneloch (jadrách)
* veľmi dobre zdokumentovaný na UNIX-like systémoch
* je relatívne malý
* je možné do štartu priradiť init skripty a priamo konfigurovať spúšťané služby
* jednoduchý pre debug a pochopenie
* dodržiava POSIX štandard

systemd:
* riadi komplexne štart systému a služieb
* jednoduché zapojenie iných programov a rozšírenie funkcií
* snaha o komplexnú integráciu služieb starajúcich sa o beh systému
* riadenie prístupových práv k file systému
* zjednodušuje boot systému

Systemd takto vyzerá ako veľmi dobrý krok, no problémom je, že už to nie je iba init, a už nedodržuje filozofiu Linuxu a nedodržiava štandardPOSIX.
No a je to problém?
v podstate nie je, pokiaľ sa na to človek pozerá očami bežného užívateľa.
Inak to už vyzerá z pohľadu mňa, ako admina a bezpečáka.

Dovolil by som si zhrnúť moje postrehy bez označenia čo je pozitívne a čo negatívne:

Voči systemd:
odklon od POSIXu
snaha urobiť linuxové distribúcie na spôsob Windows
pridáva do systému ďaľšie potencionálne zraniteľnosti, keďže na rozdiel od initu beží naďalej v systéme
časté problémy pri behu monitorovacích utilít, spôsobené kontrolou oprávnení.
jednoduchší a aj grafický manažér štartu systému
aj po štarte systému kontroluje beh systému
snaha obmedziť používanie shellu (CLI)
distribuované ako binárka
na serveroch spôsobuje kolízie pre staršie verzie programov
priúzke spojenie s RedHat
veľmi pomalé riešenie bugov

Voči SysVinit:
stabilné a overené časom.
zastaraný systém (ešte z roku 1983)
jednoduchší spôsob manažovania jednotlivých služieb
po štarte systému nezasahuje do behu
vhodnejšie na server keďže nezasahuje do behu
rýchlejší štart do desktopu
nekonfliktný s mnohými generáciami CPU a základných dosiek
nepreferovanie žiadneho DE

 

Obr. Inicializácia systému z pohľadu systemd a sysVinitu. Štart systému je u oboch rovnaký do spustenia ich služby (PID-1) kde už každý iniciuje systém iným spôsobom. systemd má beh naďalej pod kontrolou, sysV necháva systém na init scripty.

Samozrejme existuje viac init systémov ako Upstart, runit, alebo OpenRC.
Tie však teraz nie sú až toľko rozšírené.

No a čo na záver?
Pokiaľ chcete používať počítač ako bežný užívateľ a nie ste vyslovene zástancom filozofie voľnosti a pôvodných myšlienok Linuxu, pre vás nemá žiadny zmysel riešiť či máte systemd alebo sysvinit.
Je to jedno.
Druhá vec je kam speje vývoj systemd a jeho snaha nahrádzať časť služieb z kernelu alebo jeho zasahovanie do chodu vyšších vrstiev systému a možné spôsobovanie nestability.
V inom prípade ak to riešite, asi sa pridáte k Linusovi Trovaldsovi a ľuďom okolo freedesktop a bude pre vás systemd problém.

“Generic terms are generic, not the first user owns them.” Kay Sievers, one of the systemd developers.

    Key, I’m f*cking tired of the fact that you don’t fix problems in the code *you* write, so that the kernel then has to work around the problems you cause.
…I’m not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project. Because I am *not* willing to take patches from people who don’t clean up after their problems, and don’t admit that it’s their problem to fix.
Kay – one more time: you caused the problem, you need to fix it. None of this “I can do whatever I want, others have to clean up after me” crap.

Linus (Trovalds)

článok pôvodne publikovaný 1.3.2017  na linux-mint-czech.cz
Reklamy

Pridaj komentár

Zadajte svoje údaje, alebo kliknite na ikonu pre prihlásenie:

WordPress.com Logo

Na komentovanie používate váš WordPress.com účet. Odhlásiť sa /  Zmeniť )

Google photo

Na komentovanie používate váš Google účet. Odhlásiť sa /  Zmeniť )

Twitter picture

Na komentovanie používate váš Twitter účet. Odhlásiť sa /  Zmeniť )

Facebook photo

Na komentovanie používate váš Facebook účet. Odhlásiť sa /  Zmeniť )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.