Vlákno názorů k článku
Dělá systemd Linux více složitým, náchylným k chybám a nestabilním?
od paratko - Pro vas co radeji TLDR:
Maji ve firme tak...
-
paratko (neregistrovaný)
Pro vas co radeji TLDR:
Maji ve firme tak velky vendor lockin na init scriptech, ze si ani netroufli to prepsat do systemd. Aby ten moment pravdy nejak oddalili tak presli na Devuan a snazne vas prosi aby jste ho podporovali a nejaky mesic to jeste vydrzelo. Kolem toho nejaka omacka, ze jedna pani povidala ze systemd je pry nestabilni.
No a za rok mu na blogu pribudne dalsi post - "Jak nam to nevyslo s Devuanem" . -
Sid (neregistrovaný)
Co je na tom az tak nepochopitelne? :- )Napises si init ktory robi tak nestandardne kroky a zavisi na nejakych konkretnych vlastnostiach, ze proste prepisat ho do hocicoho standardneho je problem. Kolko buildovacich scriptov uz som videl takych, ze bolo jednoduchsie to cele zahodit a prepisat ako sa snazit to nejako "scivilizovat". Chapem sice co si myslel ale podla mna pri troche "snahy" dokazes skoro hocico dostat do stavu "neprenositelne"
-
mngnt (neregistrovaný)
Daj priklad, ako by bolo mozne napisat pre sysv init skript tak, aby si s nim systemd neporadil. Ked fakt nebudem vediet, ako dalej, do unitu si napisem, ze ten skript priamo zavola. Teda mozem pouzivat to, ci mma ten vendor zamkol a zaroven systemd, ktory ten skript spusti. Tu by som problem nevidel.
Buildovacie skripty su podstatne odlisna vec. -
SB (neregistrovaný)
Moc tomu nerozumím, ale spuštění skriptu v sysvinit funguje asi dost jinak (řeší vše sám, bez návaznosti) než spouštění služby v systemd (hlídání služby, čekání na inicializaci, spouštění závlislostí). Když pomocí systemd pospouštíte hromadu skriptů, bude to fungovat stále jen jako sysvinit, na to nepotřebujete systemd.
-
Palo M. (neregistrovaný)
1. Urobit vendor lock-in sam na seba je dost nepredstavitelne. Obzvlast ak ide o skripty.
2. Na tom blogu sa nepise o tom, ze by mali plno skriptov ktore "nejdu" prepisat alebo co.
3. Inak sa v tom blogu nepise nic zvlastne, takych kritik systemd uz za tie roky bolo... Skratka chlapik sa chcel vykecat, ze to skusali, nevyhovovalo im to, tak to vyhodili. Nic extra. Vtipne ale je, ako sa tu rychlo zbehla systemd uderka... -
. . (neregistrovaný)
ten vendor lockin nejspíš pochází z toho, že služby jsou v systemd spuštěný v skoro náhodném pořadí a je složité správně nastavit závislosti služeb, což se dříve tak moc řešit nemuselo. Na tomhle máme na jednom projektu několik desítek MD než se to vyladilo, pokud na to nemáš kapacitu, může to být problém, viz i daný blog post.
Řada bugů, které třeba my hlásíme nejsou ani tak bugy, ale nepochopení toho jak systemd funguje a jak s ním zacházet, opět chvilku potrvá než se tyhle stavy přestanou objevovat a aplikace s tím budou počítat, to opět není zadarmo a hned.
-
j (neregistrovaný)
90% custom veci na tuxovi startuje uplne jednoduse ... mas script, klidne par tisic radku, a ten se provadi prejne jeden radek podruhym. A zadnej jinej zpusob startu ti dodavatel nebude uplne jednoduse akceptovat prave proto, ze nehodla resit, co na cem vlastne zavisi.
Pricemz klidne muze startovat i zcela bezny soucasti systemu (mtacko, webserver ....), ale trva na tom ze to bude spoustet prave ten jejich script. Jednoduse proto, ze jednotlivy komponenty predpokladaj, ze neco vazne bezi a ne ze neco "jako bezi".
Predevsim pak nehodlaj prepisovat konfiguraci u 150 zakazniku proto, ze nejakej trotl nekde zmeni vychozi chovani.
-
SB (neregistrovaný)
j:
„...startuje uplne jednoduse ... mas script, klidne par tisic radku...“
V těch 1000 řádcích je něco extra pro danou službu, nebo obecná funkcionalita, kterou využívají všechny služby při spouštění? Jestliže to druhé, má to být společnou, odladěnou částí initu.„...ze nehodla resit, co na cem vlastne zavisi.“
A to mám zjišťovat metodou pokus-omyl, nebo jak?„Jednoduse proto, ze jednotlivy komponenty predpokladaj, ze neco vazne bezi a ne ze neco "jako bezi".“
To mi přijde v rozporu s předchozím tvrzením. Každopádně přesně toto řeší závislosti, tady není nic k nepochopení.Všimněte si, že předchozí text je obecný, netýká se jen systemd.
-
j (neregistrovaný)
Co nechapes na tom, ze takovech script deklaruje komplexni startovaci sekvenci, vcetne pripadnych testu toho, ze dana vec opravdu nastartovala. Pricemz v nonsystemd initu muzes volat i vychozi scripty nekterych sluzeb, ale v systemd nikoli, protoze nevis, jestli se to stejne bude chovat jeste pristi tejden.
-
j (neregistrovaný)
2SB: Ses gramotnej? Tak si dohledej kolikrat se menilo vychozi chovani ruznych komponent systemd. Velmi casto bez jakyhokoli upozorneni, jakyhokoli prechodnyho obdobi ...
Vis k cemu je v postfixu v konfiguraci compatibility_level = ??? Si to najdi. TAKHLE se delaj zmeny.
Uz si predelal Firewall na nftables? Zejtra du s Linusem na pivo a dohodnu se s nim, at s pristim patchem iptables vyhodi, psat to nikde nemusi. Pohoda, lidi prece opatchujou a prijdou na to sami.
-
No to je právě ono. On takový normální admin neví, co na čem v systému visí. Prostě jede podle levelů a jeho znalost závislostí končí tím, že napřed musí nahodit síť, v dalším levelu pak teprve montovat vzdálený disky, v dalším spustit služby, který používají data z nich. A neřeší, že modul z levelu X potřebuje konkrétní věc z levelu X-1, protože už má nataženo všechno... A zjišťovat závislosti metodou pokus-omyl dost bolí.
Do toho přijde systém, co se pokusí ušetřit čas a zvýšit spolehlivost při bootu tím, že nezávislý věci zpracovává paralelně. Když mu neřeknu, že potřebuju třeba Postgere před startem Apache, tak jak musím počítat s tím, že se spustí web bez DB a pude to do kytek... A co udělá náš admin? Brečí, že musí tušit, co za moduly používá a který závisí na kterým. Jako by nebyla jeho práce tohle vědět...
-
Tak pokud závislosti při startu řeší dodavatel SW, a to včetně init skriptů nebo závislostí pro systemd, a adminovi je to šumák, protože to přece není jeho práce, tak je řešení jednoduchý. Ať do toho ten admin nehrabe (protože to přece není jeho práce) a nemusí řešit skripty, závislosti ani init systém. Easy :)
-
j (neregistrovaný)
Nejodvarenejsi je admin z toho, kdyz mu nejakej pojebanej init nahodi sit a sitovy sluzby driv nez firewall a jen tak mimochodem tam jeste spusti dhcpserver.
A jinak zavislosti pro tuhle sracku != zavislosti aplikaci. To ze nejdriv musi bezet SQLko a pak teprve ma smysl startovat trebas webserver vi kazdej. Jenze kdyz ti veci startujou jedna pres druhou v naprosto random poradi a navic jeste k tomu vlastne nenastartujou, tak narazis na veci, ktery by te ani ve snu nenapadly. Protoze ocekavas, ze se takova zakladni vec bude chovat aspon trochu normalne, ale nechova.
Anzto a jelikozt tahle vec (init to ani nahodou neni) ti napriklad jakoze nastartuje trebas to SQLko, ale ono ve skutecnosti nebezi, byt existuje socket. Mno hlavne ze to je rychle ... ale zcela khovnu. A protoze prece nejses blbej admin, a mas nastaveno ze ten apache ma startovat az po SQLku, tak ti obratem nastartuje ten, jenze vlastne nic nefunguje, protoze ve skutecnosti nic nebezi. Kdyz tam pak mas nakou appku ktera ocekava ze ji to SQLko i odpovi a posle si do nej nejaky query, tak ji neodpovi nic, protoze to SQLko bude startovat trebas pristich 20 minut a appka se teda odporouci s tim, ze nema pristup do databaze.
A takhle je to se vsim. Tudiz ani tvurce aplikace nemuze tusit, dokud si na tom nenabije hubu.
-
Jasně. Takže zmrvený SQL odreportuje, že běží když ještě neběží. Zmrvená aplikace si nedokáže ověřit, že SQL doopravdy běží a klekne. Ale ne, může za to init, který po obrdžení informace o startu SQL korektně nahodí appku, která na tom závisí.
Btw, jak to v takovým případě děláš, když spustíš to SQLko pomocí skriptu, začne startovat, mezi tím se skript ukončí (už přece inicializoval binárky DB systému, teď je to na nich) a DB si klidně dalších 20 minut nabíhá. Jenomže skript té appky přijde na řadu po minutě... To přece taky musí chcípnout, ne?
