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 RE: - Dalsi internetovy kokot. Ze jeho team neni schopny...
-
. . (neregistrovaný)
další diskuzní ko**t. Četl jsi ten blog, tam důvody docela konkrétně popisuje. Nemít dostatek lidské kapacit a nebýt schopný jsou rozdílné věci.
Napsat bug report zabere také dost času, to není zadarmo, kolikrát nějakou dobu vůbec trvá nají tu špatnou komponentu, aby se vyplnit správný bug report. Na jednom projektu máme cca 500 serverů se systemd a bugů kolem systemd se řeší každý měsíc několik, ještě nějakou dobu potrvá než se znalosti interního týmu dostanou na úroveň, že se s tím naučí žít, ale ten přechod zadarmo není.
Systemd je mnohem složitější a mnohem monoličtější než je v linuxu zvykem.
-
RE: (neregistrovaný)
Ano cetl a evidentne pobiram logiku vic nez ty, protoze argument “rozmrdalo nam to sit” -> systemd na ubuntu je drazsi nez nase suprdistro je jak od maleho ditete. Zadne podklady pro argumentaci. Stejne jako komentar od tebe, 500 servru a mame problemy, a co kurva jako? Neumite si to nakonfigurovat? Mate problemy s lidma co to neumi? Vsechny ty problemy s 500 serverama jsou zpusobeny systemd? Ze systemd neodpovida nejake pseudo-nabozenske-gnu-idologii?? A co?
-
Ľubomír Mlích (neregistrovaný)
Imho je přijatelné, aby někdo jiný měl jiný názor. Borec má hostingovou firmu a potřebuje mít co nejnižší náklady, aby měl co nejvyšší zisk. Je to jeho názor a nechápu proč bychom si o něm měli kvůli tomu myslet něco špatné nebo jej dokonce urážet. Není to malé dítě, umí vést hostingovou firmu. Má s tím spoustu zkušeností. Nemusíme dělat to, co on říká, máme svobodnou vůli. Ale můžeme vzít jeho zkušenost v potaz. A poděkovat mu, že s námi svou zkušenost sdílí.
-
Jenže tohle není troll, jen protivný připomínač naší uživatelské/administrátorské/manažerské neschopnosti. Nejsou lidi? A za co je placen management? Stovky serverů ve farmě/firmě? A proč je to ZOO a nikoli v zásadě HW a SW homogenní prostředí? Že to požaduje dodavatel hyperIS? A proč se to bere od něj, když je tolik jiných řešení? Ano, i ve farmách/firmách je spousta stereotypního a pasivně závislého chování v mixu s mizerným managementem.
-
Nejsou lidi? A za co je placen management? Stovky serverů ve farmě/firmě?
Hele a proc by firma mela najimat trikrat tolik adminu jen proto, ze nejaky blb vymyslel systemd, vsichni se toho hned musi chytit a nasledne ten blb kazdy mesic doprasi v tom sve zazraku neco jineho, ze se admini nestaci divit a porad zapoli s necim, co prestalo fungovat? Systemd je v jeste horsim stavu, nez Widle 10. Ty jsou momentalne alespon ve stadiu bety.
-
nico (neregistrovaný)
Fantastický systemd. upgrade systemd , pokus o shutdown -r ,ale co to, stroj se neotočí, druhý (jiná konfigurace) taky ne .. Mít to z ruky, tak super.. Díky za pytel sraček systemd ( a to si unity napsat umím) .Ale
toho času, co to sežralo,než se člověk dostal tam, kde byl automaticky léta s initem. A pořád "to" přitahuje
pozornost a žere čas dál, protože systemd.. Takže jedině se ZFS ,kde mám možnost fofrem vodrolovat
taknějak né úplně povedenej upgrade zpátky, protože jinak bolehlav. -
MarSik (neregistrovaný)
Mám k systemd ekosystému taky výhrady, ale to už si opravdu nikdo nepamatuje třeba vytuhlé systémy když se NFS umount provedl moc brzo během shutdownu a podobné problémy se Sys V initem?
Zase si ten Sys V init tak neidealizujte, ta horda skriptů měla taky slušné množství bugů.
-
Bohužel ale také přináší problémy, které by bez něj nebyly. S problémy, které se dají řešit nastavením ap. by si každý admin měl nejspíš poradit, stejně jako si poradil s problémy v init skriptech. Blbé je, když se systemd chová v podstatě nedeterministicky, např. když z 10 startů 2× nějaká služba nenastartuje, v logu je kulové a stav, kdy je jasné, že další restart to "nějak sám vyřeší" je dost pitomý, na tohle si linuxoví admini odmítají zvykat.
-
. . (neregistrovaný)
problémy s tím, že z 10 retartů to dvakrát selže jsou z pravidla kvůli špatným závislostem nebo nízkým timeoutům, systemd při každém startu rozhodne o trochu jiném pořadí služeb. Je to porod to řešit, máme na to ale nástroje, které nám z logu vyzuálně zobrazují pořadí startu aplikací a z toho ruční analýzou zjišťujeme, které pořadí je ok a které ne. Celé to je o tom, že doteď to startovalo pěkně pomalu a nic se nemuselo řešit.
U java aplikací (kterých je v enterprise prostředí drtivá většina) je zase problém, když jich startuji příliš najednou, generují startem příliš vysokou zátěž a při souběhu nám padají jak jablka na divných chybách, takže opět je musíme dávat mezi sebou do závislostí, aby startovali postupně. Tohle je podle mě jasná chyba systemd, doteď nebylo potřeba řešit, teď je, nemluvě o tom, že řada OS balíčků tohle také nemá dobře pořešené.
Co o to, člověk si na to zvykne a nějak to vyladí, ale říkat, že pokud mi systemd nefunguje, je amatér je občas od některých dost ostřelené :)
-
j (neregistrovaný)
2Czz: Ze se to kdykoli zcela libovolne podela?
https://dev.overpass-api.de/blog/systemd.html
Ale jo, jiste jen dalsi z rady blbcu ktery to neumej nastavit.
-
j (neregistrovaný)
Jenze kdyz mas normalni init, tak je to JEN init. Kdyz ti nevyhovuje logger nebo ti pada ... tak ho vymenis za jinej. Kdyz ti nevyhovuje cron nebo pada, tak ho vymenis za jinej ... a u kazdy jedny kompomenty, ktera je v systemd nacpana natvrdo, mas bez sytemd vyber z 10+ alternativ.
Navic nemusis ve vychozim stavu resit sracky typu ze se neco "samo" restartuje, protoze se nic samo restartovat nebude. Pokud chces aby se neco restartlo samo, nahodis si na to dalsi tool, kterej dela jen a pouze ten restart, pripadne tool, kterej nejdriv peclive checkne co se ty zcela konkretni servise stalo, a teprve pak ji pripadne zkusi nastartovat znova.
A i kdyz ten zabugovanej script nebude fungovat vubec, tak si kazdej jeden admin umi lusknutim prstu napsat svuj. A nemusi resit binarni sracky a restarty celyho systemu jen proto, ze potrebuje opravit dojebanej init ... aby za 5 minut zjistil, ze neopravil nic, zato dalsi 2 bugy ze ma novy.
Vubec pak nemluve o vecech typu paralelni start cehokoli, protoze to je specielne na serverech, kde se pouziva 99% instanci tuxe, vec vyslovene nechtena. Jednoduse proto, ze kdyz neco zbuchne, chce admin vedet co to je a ne dva dny zkoumat, ktera z 20 zaroven startujicich servis to zapricinila.
-
SB (neregistrovaný)
j:
„Navic nemusis ve vychozim stavu resit sracky typu ze se neco "samo" restartuje, protoze se nic samo restartovat nebude. Pokud chces aby se neco restartlo samo, nahodis si na to dalsi tool, kterej dela jen a pouze ten restart, pripadne tool, kterej nejdriv peclive checkne co se ty zcela konkretni servise stalo, a teprve pak ji pripadne zkusi nastartovat znova.“
Tady vidím chybu přístupu:
1. proč si budu pro každou službu, kterou potřebuju znovunahazovat (a to je asi většina), dělat nástroj, který to udělá?
2. Jestliže koncepčně přijmu (a zařídím), že každá služba si před spuštěním udělá testy, které když nedopadnou, tak se nespustí, proč by to potom nemohl jednotně spouštět systemd?„Vubec pak nemluve o vecech typu paralelni start cehokoli, protoze to je specielne na serverech, kde se pouziva 99% instanci tuxe, vec vyslovene nechtena. Jednoduse proto, ze kdyz neco zbuchne, chce admin vedet co to je a ne dva dny zkoumat, ktera z 20 zaroven startujicich servis to zapricinila.“
To samé: Jestliže nejsou služby bez vzájemných závislostí schopny samostatně nastartovat, někde je chyba, kterou pouze sekvenčním spouštěním omrdávám, což je ale stejně opět sázkou do loterie - změníte pořadí spuštění u zdánlivě nesouvisejících služem a ono to nenajede?
Dostatečné logování je samozřejmostí, nemá-li je služba nebo systemd, je to špatně.Nezastávám se systemd, ale koncepční chybu v něm nevidím, spíš mi připadá, že se pořád někdo snaží dokola vynalézat hranaté kolo, a to ještě na koleně.
P. S.: Dostanu mínusy, přestože mi jsou inicializační systémy u pr-dele?
-
j (neregistrovaný)
1) normalni je ze sluzba bezi a nepada
2) kdyz padne, ma to nejakej duvod
3) normalni je odstranit pricinu padu a ne neco restartovat
4) restart sluzby bez analyzy priciny muze klidne nenavratne znicit data (muze dojit k tomu, ze se vse tvari OK, a pritom nekde doslo ke zmene, kterou si nasledne i odzalohujes a za mesic zjistis, ze data jsou v riti)5) sluzba sama sebe nemuze odestovat, protoze to nejde. Jak zjisti SQLko samo o sobe jestli bezi nebo nebezi?
6) kdyz nebezi, jak o tom poda nejakou informaci? A ne, systemd to resit NEUMI. Protoze NEVI jestli to bezi.
7) kdyz nebezi, pripadne padlo, jak zjisti proc?8) paralelni start rozmrdava logy => nejmin 10x vic casu na zjistovani, co se vlastne delo a proc to padlo
9) pri paralelnim startu dochazi k tomu, ze zatizeni stroje je vyrazne vetsi a spousta veci kvuli tomu muze timeoutovat, pricemz se to na kazdym jednom stroji muze chovat uplne jinak.
10) pri paralelnim stratu se ti klidne muze stat, ze vycerpas nejakej typ zdroje - treba ti dojde ram.Me je init naprosto uprd.ele, dokud dela co ma. Systemd to nedela.
-
SB (neregistrovaný)
j:
1) a 2) Normální je počítat s chybou, protože každý SW má chybu.
3) Když budu chybu hledat 3 hodiny, tak ta služba mezitím nepojede?
4) Nikde není napsané, že test při spouštění služby nemůže uložit informace o předchozím, nebo aktuálním pádu, či zazálohovat data. Automaticky! Je-li to problém, tak to nerestartujte, ale pak to prostě nepojede.
5) Otestováním socketu? Primitivním pythoním klientem s extra účtem v DB pro např. testovací select? Nebo se to ponechá až na aplikaci využívající SQL? Představivosti se meze nekladou.
6) Buďto najdete v logu systemd nenaběhnutí služby, nebo služba při spouštěcích testech stihla něco zalogovat. To je ale věcí konstrukce té služby, to nesouvisí se systemd.
7) Vizte 6).
8) Nestačí vyfiltrovat pouze logy od závislostí (zdali to zvládne journald, však netuším)?
9) a 10) Systemd má jakési možnosti omezení zdrojů pro služby, ale je třeba znát požadavky služeb. Víc o tom nevím. -
j (neregistrovaný)
2SB: jasne, takze ty lecis chyby aplikaci tak, ze je porad dokola restartujes ...
Kdyz servisa nefunguje tak nefunguje a je treba zjistit proc, mozna to potrva hodinu, mozna tejden. Ale jo, vyridim v tvoji bance ze to maj proste restartnou, ze to sice mozna proste random zmeni ty cisilka kterym se rika zustatek, ale to je vpohode, hlavne ze to bezi.
Zalohovat dat je ti khovnu, kdyz na zmenu tech dat prijdes mozna za mesic, mozna za 1/2 roku. Tys zcela zjevne vzivote nic neadminoval, a tvoje zodpovednost je na bodu mrazu.
Jo? Vazne? A co asi tak otestuju na socketu? Aha, nic. Ty si vazne myslis ze jakejkoli slozitejsi system otestujes tak, ze do nej posles select? Lol ...
V logu systemd nenajdes nic, protoze zadny logy mit nebudes. A i kdyz mit budes, bude tam neco jako ze to prece uspesne nastartovalo, protoze neco v pameti bezi a vratilo to OK.
2Ladislav Michl: Jasne, takze kazdej admin bude neustale vynakladat desitky clovekohodin prace na to, aby terminoval to, co prej ma bejt nejvetsi vyhoda systemd (openrc paralelni start umi mimochodem taky, ale nedela to defaultne, z mnoha dobrych duvodu) ...
A vysledkem bude, ze bude mit sice seriovej start, ale k tomu pseudo init deravej jak reseto a zabugovanej jak svin.
Bonusem pak bude resit, kterej kokot mu odstrelil screen, aby se dozvedel, ze to 30 let vlastne funguje uplne spatne, a ze jedine nakej koko Lennart vi, jak to ma fungovat spravne.
2Petr M:
"Mějme klasický, stolní PC"
Zadny stoni PC nemame, mame miliardu serveru. A kdyz na serveru bezi 10 sluzeb, tak zjevne admin chce, aby bezely vsechny. A ne jenom nektery, podle toho jak se systemd zrovna vyspi. -
Ladislav Michl (neregistrovaný)
Ale vůbec ne, pane j. Psal jsem jen, že to jde. Prostě pro Vaši informaci. Rozumný admin přeci nebude vynakládat desítky člověkohodin na něco, co v jiných initech funguje od přirození. A vůbec nejrozumnější admin, když zjistí, že mu systemd přináší samé otravné problémy, tento vůbec nepoužívá. Nechá si ho jen na jednom stroji, prostě pro zajímavost, aby nám mohl jednou za čas napsat, co ten koko Lennart zase domrvil (zrovna v tomhle (screen) případě to není věc Lennarta, ale toho, kdo to tak nakonfiguroval, tedy default konfigurace, která přišla s balíkem distribuce, ale to sem nebudeme tahat, protože když to nešlo vysvětlit dvakrát, po třetí to taky nepude)
-
j (neregistrovaný)
2Ladislav Michl: Az na ten detail ze ten admin nema casto na vyber, protoze dodavatel prohlasi, ze tohle podporuje jen na RH. A jasne, kazdej maintainer v kazdym distru bude neustale zkoumat, jak se u kazdyho jednoho baliku zmenila nejaka defaultni konfigurace, aby ji zmenil na fungujici.
Jo aha, on mel prej systemd maintainerum zjednodusit praci ... lol.
-
zrovna v tomhle (screen) případě to není věc Lennarta, ale toho, kdo to tak nakonfiguroval, tedy default konfigurace, která přišla s balíkem distribuce, ale to sem nebudeme tahat, protože když to nešlo vysvětlit dvakrát, po třetí to taky nepude
Pokud vím, tak tohle chování udělali výchozí autoři systemd.
-
"Zadny stoni PC nemame, mame miliardu serveru. A kdyz na serveru bezi 10 sluzeb, tak zjevne admin chce, aby bezely vsechny. A ne jenom nektery, podle toho jak se systemd zrovna vyspi."
OK, tak jinak. Mějme server, běží na něm 10 služeb. Každá závisí na pěti modulech (něco z toho je společný). Jaký prospěch budu mít jako provozovatel datacentra z toho, že
- při zacyklení initu v jednom libovolným skriptu neexistuje timeout, takže nenaběhne ani jedna z těch služeb?
- pokud je problém se serverem a znovu ho nahazuju, tak bere jeden modul za druhým, skoro hodinu chroupe a ještě neběží nic, i když by to paralelně dal do 10 minut?
- budu platit admina, který nedokáže do textovýho souboru napsat "tohle nastartuj až po firewallu" a upravit v konfiguračním souboru timeout? -
Petr M (neregistrovaný)
Dovol tři dotazy.
Mějme klasický, stolní PC (s nějakým desktopem). Na HDD jsou fotky dovolené, chci je vystavit na DLNA, abych se mohl pochlubit. A je tam připojena tiskárna, sdílená přes CUPS. Navíc se dokumenty synchronizují přes NextCloud.
Jakou výhodu poskytne sekvenční start v případě, že:
1) se zacyklí init skript pro CUPS a init thread se zasekne? Při paralelním initu totiž naskočí aspoň něco, zacyklený skript vytimeoutuje a sice netiskneme, ale jinak fungujeme.
2) si uživatel stěžuje, že boot trvá dlouho a vytížení systému během bootu je jenom cca 8%?
3) tam budu mít 150 skriptů, z toho teoreticky odlišený jenom cestou k binárce a parametrama a prakticky jenom tři z nich adekvátně otestovaný, proti otestované standardní funkcionalitě systému, která jenom dostane ty rozdíly jako parametry? -
Sice mám nejvíce zkušeností se svými třemi stroji s Archem a Manjarem, ale přesto nepamatuji, že by se mi cokoli v rámci bootu/initu rozsypalo, a to včetně dost častých aktualizací. Že by opravdu šlo pouze o důsledné vyhovění tomu, co si systemd žádá (a není toho moc)? Jistě že je to monolit versus KISS, ale zde jde snad o princip fukčnosti, nikoli ideologii, nebo se mýlím?
-
. . (neregistrovaný)
a kde máš získat znalosti než právě tím, že to provozuješ? Tady vůbec nejde o to umět nebo neumět, na OS se běžně provozují i aplikace, které nejsou z managovaných balíčků a pokud tahle aplikace a systemd mají nějakou regresy ač dříve nic takového nebylo, je to buď špatně napsaná aplikace nebo problém v systemd. Redhat nám zatím tyhle "bugy" často uznává a posílá patche, to považuji za potvrzení toho, že to není tak jednoznačné na čí straně je chyba.
Snes se na zem do reality. Těch zásahů do *.service služeb, které se na projektech museli udělat je poměrně velké množství, něco jsou balíčky spravované redhatem, něco vendorem služby, něco jsou interní. Ano, většina problém pramění z toho, že chybí patřičné detailní znalosti a ty nabrat něco stojí, zadarmo to není.
Řvát, že někdo něco neumí a urážet ho je opravdu super způsob, jak říct, že já jsem vlastně ten king, který to umí. Děkuji, chápu tvoje postoje.
-
Klid Tome, ono není od věci si položit otázku, co vyvolalo zásahy do *.service, které jsou tak složité, že si toho admin vůbec všimne. Práve services jsou v systemd dobře zdokumentovány a práce s nimi je dost analogická jako s předchozími moduly a démony u sys-V-initu. Správcem se nestává ten, koho uvedou do pozice, ale ten, kdo pochopí systém a vyhoví mu při jeho správě.
-
. . (neregistrovaný)
nekritizuji systemd, chtěl jsem jen ukázat, že s sebou nese nezanedbatelné náklady a kdo na ně nemá, dělá mu jeho používání problémy.
Nejsem administrátor, jen vidím několikaletý proces, který vedl k zavedení systemd do bezproblémové produkce u globálních hráčů, ty požadavky a prostředky jsou trochu jiné, počet bugů, které se v systemd patchoval jde do desítek, a to jsou ty, které jsem viděl.
Zásah do balíčkových *.service s sebou nese potřebu při updatu kontrolovat jestli nedošlo ke změně v původní definici, ne vždy oprava *.service jde rychle do upstreamu a opět to s sebou nese dodatečné náklady, které dříve nebyly potřeba. Dnes je již stav jiný než před dvě roky.
-
Navyse sa jednemu moze stat, zeten bugreport vyplni a Lennart mu ho zavre s tym, ze to nie je bug, pretoze na Lennartovej masine to nepada alebo sa to nedeje (ergo, konfiguracia ktoru ma zalujuci pouzivatel podla Lennarta nie je podporovana). Vid minuly evidentny local privilege escalation bug v parseri na masinach, kde neboli vyzadovane silne restrikcie pre uzivatelske ucty.
-
My jednou jeden init, který byl tak jednoduchý a tak malý, že si jej každý, kdo jej chtěl použít, musel přizpůsobit ku obrazu svému - svého IT systému, který byl včetně aplikací také celkem malý, ale silný natolik, že jednoduše definoval, co musí init respektovat. Jenže jak vše bujelo a rostlo, init se zamyslel a pochopil, že již nelze být tak malý a že je již sám systémem, má-li spouštět všechny ty procesy včetně aplikací. Proto vyhlásil, že má-li nadále spouštět stále více stále různorodější procesy a aplikace, navíc odděleně pro systém a pro jeho uživatele, musí mu tyto procesy a aplikace splnit jeho systémová přání, protože on je již natolik silný systém, že je nesmyslné, aby se přizpůsoboval slabším systémům. A tak se stalo, že zlenivělí tvůrci aplikací spouštěných init systémem se učili plnit přání init systému, aby jím tyto aplikace mohly být vůbec spuštěny. Jenže to by nebyli tvůrci aplikací, aby si nepomysleli, že oni určují pravidla a nějaký init jim do toho nemá co kecat. to se ale podivili, když jim přestaly být spolehlivě spouštěny jejich aplikace, jimž pro spuštění nevytvořili vhodné prostředí. A do toho začari reptat uživatelé IT systému a ti, kteří tuto pohádku neznají, reptají dodnes a ukazují zamračeně na init systém. A zazvonil konec a pohádky je konec. Už chápete, milé děti?
-
Byl jednou jeden init, který byl tak jednoduchý a tak malý, že si jej každý, kdo jej chtěl použít, musel přizpůsobit ku obrazu svému - svého IT systému, který byl včetně aplikací také celkem malý, ale silný natolik, že jednoduše definoval, co musí init respektovat. Jenže jak vše bujelo a rostlo, init se zamyslel a pochopil, že již nelze být tak malý a že musí být sám systémem, má-li spouštět všechny ty procesy včetně aplikací řádně. Proto vyhlásil, že má-li nadále spouštět stále více stále různorodějších procesů a aplikací, navíc odděleně pro systém a pro jeho uživatele, musí mu tyto procesy a aplikace splnit jeho systémová přání, protože on je již natolik silný systém, že je nesmyslné, aby se přizpůsoboval slabším. A tak se stalo, že zlenivělí tvůrci aplikací spouštěných init systémem se učili plnit přání init systému, aby jím mohly být tyto aplikace vůbec spuštěny. Jenže to by nebyli tvůrci aplikací, aby si nepomysleli, že oni určují pravidla a nějaký init jim do toho nemá co kecat. To se ale podivili, když jim přestaly být spolehlivě spouštěny jejich aplikace, jimž pro spuštění nevytvořili vhodné prostředí s respektem k init systému. A do toho začali reptat uživatelé IT systému a ti, kteří tuto pohádku neznají, reptají dodnes a ukazují zamračeně na init systém. A zazvonil konec a pohádky je konec. Už chápete, milé děti?
ČLÁNKY DO MAILU