CEO malé švýcarské internetové a hostingové společnosti Ungleich Nico Schottelius sepsal na svém blogu důvody, proč jeho firma raději používá Devuan.
Hlavním důvodem jsou náklady, jeho malá firma nemá kapacity odstraňovat problémy způsobené systemd. Navíc systemd představuje podle Nica i bezpečnostní riziko. Dále se ptá, proč lidé upřednostňují Linux před Windows? Protože jsou příliš složitá, náchylná k chybám a nestabilní. Stejné věci vytýká také systemd.
(zdroj: slashdot)
Dobrá ironie. Ono totiž není od věci si zjistit, které init (sub)systémy zvládají dnešní masivně heterogenní HW i SW. Ty z dřevních dob na více než jednoduché věci prostě nestačí a kladou tak zvýšené nároky na uživatele, který má rozlišovat mesi systémovým a uživatelským prostorem, vybírat k natažení správný firmware a podobné laskominy.
Z pohledu absolutního laika mu klidně věřím, ok, systemd je složitý a nebezpečný.
Pak ale nějak nechápu, proč Red Hat Enterprise Linux, SUSE Linux Enterprise Server, Debian a další na něj přešli. Jim nejde o bezpečnost a stabilitu?
Právě že při původní myšlence o to šlo.
Bezpečnější je poskytnout parametry jedné otestované funkci, než psát 100x podobnou funkci.
Bezpečnější je, když kontrolu nad během závislostí má jeden modul, než 50 skriptů - který se navíc spustí jednou a nemůžou tak ohlídat, že modul spadl.
Stabilnější je systém z několika částí, kde pád jedné neovlivní druhou. V klasickým initu se jede na rostoucí úroveň, takže třeba nemožnost spustit web server nedovolí spustit třeba mail server, pokud init zamrzne. Při paralelním initu několika stromů závislostí nenaběhne jednom ta část, kde je problém v závislostech.
...
Jenom se to nějak vymklo z ruky...
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.
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?
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.
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.
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.
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é :)
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.
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.
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?
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.
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.
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.
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)
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?
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?
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ě.
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?
Na problemy so systemd je odpoved pre pana jednoducha, Vas tim patri do spodnych 99% podla schopnsopti
Parallel programmers not prepared for the glorious revolution
By Wily Ferret
Tue Nov 27 2007, 12:28
INTEL RECKONS barely one per cent of software programmers are prepared to face the challenge of parallel programming, which the hardware giant (unsurprisingly) reckons is the future of development.
https://www.theinquirer.net/inquirer/news/1026585/programmers-prepared-glorious
Software needs meaty cores, not thin, stringy ARMs, says Intel
By Simon Sharwood, 26 Feb 2014
“The world has a big issue around vectorisation and parallelisation of code,” Graylish said. “99% of code isn't written that way.” Graylish also feels “defining a workload that can run in 1000 cores is hard.”
Most software, Graylish added, “still requires a big meaty core” and Intel is happy to provide them.
http://www.theregister.co.uk/2014/02/26/software_needs_meaty_cores_not_thin_stringy_arms_says_intel/
Horne 1% pouzivatelov s tym nema problem, lebo vie, ako napsisat Unity, aby nevznikol paraleny hazard a tym padom problem..
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" .
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"
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.
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.
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...
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.
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.
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.
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.
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 :)
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?
na servri mam Alpine, to je pravda, zabudol som na to. Inak na vsetkych PC v rodine (asi 5) je Void a nemam s nim problem. V podstate nemam so ziadnou distribuciou problem, doteraz, cca 3 roky som pouzival Ubuntu, jedina vec, ktora ma vie k smrti vytocit je systemd. To mi do baraku uz fakt nemoze. Zial v praci si ale nevyberieme, ze pan Redhat?
systemd na serveru je nebezpecna vec. Moj problem s nim je, ze nikto netusi, aku dalsiu sluzbu sa rozhodnu pani experti zo systemd pribalit do balicka systemd a co vsetko tym pokazia.
Pri jednom dist-upgrade stable debianu, sa takto na moj secondary DNS dostal systemd-resolved, ktory samozrejme obsadil port a vdaka tomu PowerDNS nefungoval. Predtym to islo x rokov bez problemov, nikto sa mi na serveri nesnazil spustat sluzby, ktore som neziadal.
Preto moja otazka pri systemd znie, co dalsie si systemd nainstaluje - systemd-httpd, systemd-ldapd, systemd-smtpd ? Ktora dalsia sluzba pojde vdaka upgradu do kytek, pretoze sa niekto rozhodne, ze toto by sa nam hodilo do 'architektury' a doteraz to vsetci robili zle, tak to spravime lepsie....
Preto moja otazka pri systemd znie, co dalsie si systemd nainstaluje
Nic, stejně jako si nenainstaloval systemd-resolved. Balíčky neinstaluje systemd, ale správce systému prostřednictvím distribučního správce balíčků.
Opět vedle, po stažení oficiálního tarballu systemd je uvnitř komponenta systemd-resolved = je přímou součástí systemd není zvlášť. Nedá se to stáhnout zvlášť, nedá se to používat bez systemd, není to samostatná věc ani projekt. Je to komponenta, žádná samostatná věc. Není se pak čemu divit, že to v distribuci také nerozpitvávají na více částí a tak jako to udělali autoři tohoto software tak to je nakonec i balíčku distribuce. Jediné co se dá udělat je zakázat tuto komponentu při kompilaci systemd, pak ta komponenta není, ale zkompilovat ji zvlášť nespíš ani nejde.
PS: Vy znáte distro, které má systemd-resolved zvlášť, že říkáte, že to je problém dister nikoli autora(ů) tohoto software, který to udělal jako nedílnou součást zdrojáků systemd?
Ano, je to komponenta, dá se to distribuovat zvlášť, dá se to spouštět zvlášť, nebo se to spouštět vůbec nemusí. Pokud se to v Debianu nainstaluje a a aktivuje samo, přestože je nainstalovaný jiný DNS resolver, je to problém Debianu. Co by s tím asi tak autoři systemd mohli dělat? To už od teď nikdo nesmí naprogramovat DNS resolver, protože jinak ho někdo v Debianu hned nainstaluje a spustí při startu (pokud to opravdu dělá)? Já používám systemd na různých distribucích, a nikde jsem neměl problém s tím, že by se mi systemd-resolver pouštěl, když nechci.
Já spíš doteď nechápu, proč Debian každou nainstalovanou službu hned aktivuje a spustí. Nebýt toho, tak si nejspíš toho přibaleného resolved ani nevšimne…
To že systém aktivuje a spustí nového démona je chyba systemd... Aha.
Jestli to spíš nebude to, že se systemd během upgrade nerozhodl enablovat službu, protože usoudil, že ji nějaká jiná potřebuje a "nechápal", že už jiná konkurenční je/bude enabled během upgrade, ale Lennart s tím, že by někdo mohl upgradovat z jiného initu, takže ta konkurenční se dostane konfigurace systemd až v nějakém dalším kroku upgrade jaksi nepočítá a zapne si svůj dle něj správný "výchozí" stav.
Z toho bych OS nevinil :).
Systemd dělá to, co dostane befelem. Spusť X, postup je napřed Y a Z, potom teprve X. A dej vědět, když se X nerozběhne do 20s po startu závislostí.
Někdo mu musí dát ten befel, kdy a jak tu součást spustí. Sám si nezjistí, že má nějaký modul v systému navíc, ani závislosti. Kdyby byl tak moc vševědoucí, tak nepotřebuje skripty s nastavením.
Takže otázka je, kdo a proč mu dal ten befel? A odověď je, že autoři distra, aby tě vytočili.
A tohle není?
„Jestli to spíš nebude to, že se systemd během upgrade nerozhodl enablovat službu, protože usoudil, že ji nějaká jiná potřebuje a "nechápal", že už jiná konkurenční je/bude enabled během upgrade, ale Lennart s tím, že by někdo mohl upgradovat z jiného initu, takže ta konkurenční se dostane konfigurace systemd až v nějakém dalším kroku upgrade jaksi nepočítá a zapne si svůj dle něj správný "výchozí" stav.
Z toho bych OS nevinil :).“
A tohle není?
Určitě je (tedy kromě zkušenosti, že tyhle podivnosti systemd také umí), ale snažím mu to naznačit už chvíli a nějak to nechápe, tak jsem si myslel, že by to mohl pochopit, když to dostane stejně zpátky.
PS: A klasika, Kate to pochopila hned a s přehledem, to zas bude mít někdo ostudu ;-), takže děkuji za nahrávku :-)
To (ne)spouštění lze řešit přes policy-rc.d, akorát některé postinst skripty nezvládnou, pokud se služba nespustí.
Debianní policy je, že služby ve výchozí konfiguraci nesmí naslouchat na síti ani umožňovat měnit systém, tak by automatický start neměl mít bezpečnostní implikace, a protože některé balíčky nejdou nastavit, aniž by běžely služby, na kterých závisí (třeba D-Bus), je lepší spouštět ty služby automaticky, než aby selhala instalace.
Akurat ze v centos, fedore je systemd-resoved v stave vendor disabled, tym padom predpokladam ze bude aj v redhate... Cize to aky je systemd v debiane rozd... pokazeny nie je problem autorov systemd ale je to problem diletantov co dali distro do kopy v sucinnosti s diletantmi co to distro pouzivaju...
Obecne init system, ktery ma v sobe 2 roky bug kde se zasekne na Reached target shutdown a nerestartuje system je absolutni kokotina. Kdyz clovec chce restartovat server aby na nem mel iKVM jinak ma smulu. At se vyserou na systemd-resolved a opravi zakladni veci nez se zacnou srat do vseho ostatniho.
treba tu https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917
https://github.com/systemd/systemd/issues/1615
https://github.com/systemd/systemd/issues/6115
https://github.com/systemd/systemd/issues/4986
Ubuntu 16.04, Debian 9, CentOS 7.4
Na vsech distrech se nam to obcas zasekne, obcas restartuje, asi jak se systemd vyspi. Obcas se to zasekne na 15 minut, obcas se to nerestarttuje ani po 4 hodinach.
Zeptat se googlu umím taky - protože soudě podle odkazů, přesně tak seznam přišel na svět. Mezi těmi odkazy žádná chyba, která by visela dva roky není. A ne, nejsem tak najivní, abych si myslel, že jste to četl nebo se dokonce snažil pochopit, co se tam píše.
Jinak takto popsaný problém není možné opravit. Je ovšem možné nakonfigurovat systemd tak, aby po vypršení timeoutu služby pozabíjel, případně nastavit hw watchdog, aby resetoval celý systém, když se něco stane samotnému systemd. Je to ojebávka, ale pokud nechcete věnovat čas zjištění, co se tam stalo, nedá se nic dělat.
jj, poridil sem si novy auto, umi prej spoustu uzasnych ficur, sterace se zapnou kdyz prsi, svetla roznou kdyz je tma, samo to brzi, samo zataci ... ma jen takovou drobnou vadu ... nejezdi. Rikali mi v servisu, ze kdyz si pripojim analyzator k ridici jednotce a dodam jim bugreport, ze to mozna i opravej. Nebo me taky poslou dopr.dele s tim, ze takhle to fungovat ma.
No nic, soused mi venoval trabose, sice nema ty uzasny ficury, ale jezdi a ridici jednotku nema vubec.
Tak největší problém systemd je, že žádný jeden systemd neexistuje. Takže sen mnoha diskutující před x lety, jak linuxu chybí jednotné rozhraní a jak se nedají psát init skripty pro 20 distribucí a jak to všechno systemd změní, jsou ty tam.
Dřív byl součástí systemd třeba nspawn, takže se dalo spolehnout na to, že všude kde je systemd, je i nspawn. Dneska je to oddělený balíček.
Součástí systemd je networkd, ale každá distribuce si tahá vlastní ovládátko sítě a networkd je masked. Totéž platí pro resolved, masked a co distribuce, to jiné řešení dns překladů.
Další věc je třeba timesyncd. By default vypnutý a každé distro si to řeší po svém. V debianu stačí odinstalovat ntpd a zapnout timesync. No, jenže když se stejný postup udělá na CentOS, tak synchronizace nefunguje. Proč? Protože CentOS nemá timesyncd a přes systemd příkaze timedatectl se ovládá ntpd. Na RHEL je potom chronyd.
Rozumím tomu, že si každá distribuce může zvolit defaultní programy, ale nerozumím tomu, proč "sjednocující prvek" linuxového světa musí každá distribuce ojebat po svém. V Debu to naštěstí ještě jde, standardně dávám pryč ntpd, network manager a ty ifupdown skripty a nastavím networkd, resolved a timesync. A nainstaluju nspawn (systemd-container). Nezblázním se z toho. Ale to, že CentOS/RHEL ty některé součásti systemd tam ani nemá, tak to mě fakt překvapilo.
Takže tolik k té jednotě.
A to nemluvím o zabugovanosti. O tom, jak za všechny chyby systemd může někdo jinej, o tom, jak snadno se to používá (narážím na to, že ini like pro psaní unit není tak úplně ini like - není nad design s důrazem na nejmenší překvapení).
Takže dřív se možná řešilo 20 různých dister, dnes se musí řešit 20 různých konfigurací systemd. Nevím, zda jsme si pomohli.
Je to kapet lepsi. Distra se od dister odlisovaly protoze medved a ja to umim lepe. Jako politicke strany, nelibi se mi zalozim novou. Systemd je spise neco jako auto. Nekomu dnes motor funguje na drevny plyn, nekomu na biomasu, extremy. Ale drive ci pozdeji to distra budou vykradat jen od nejvetsich a bude tu jen motor na beznin, naftu a elektrinu. Z 20 implementaci systemd bude jen debianovske, redhatacke a susacke.
No ten můj komentář byl spíš rýpnutí do diskusí před x lety. Mnoho diskutujících nadávalo, že linux je roztříštěný a že systemd přinese jednotný systém a bude to všude stejné. Po pár letech se ukazuje, že ani systemd není všude stejný (a to dokonce ani na OS od firmy, která vývojáře systemd platí), takže ani na tu jednotnost se nelze spolehnout.
Jinak admini (nebo teda já, abych nemluvil za ostatní) chtějí především funkční programy. Myslím, že i tato diskuse ukázala, v čem je problém
RC skripty rozhodně nemusí mít 1000 řádků. Pokud mají, tak je něco špatně. S daným programem. Normální rc skripty mají start a stop (pokud programu nestačí poslat SIGTERM) a tím to prostě hasne. Většina skriptů v bsd jsou přesně této povahy. Start a šmytec. Tj do systemd unity stačí dát totéž do ExecStart a je to.
No jenže jak i tato diskuse ukázala, tak problém není ani tak v konkrétním rc systému, jako spíš v těch programech. Pokud program závisející na db se není schopen vyrovnat s tím, že db při jeho startu ještě neběží, tak je špatně napsaný. Protože s výpadkem spojení do db se musí vyrovnat i za provozu (nebo nevím, zda někdo skutečně restartuje všechny závislé aplikace jen proto, že na chvíli vypadlo spojení na db, já ne a nevidím nejmenší důvod to dělat).
A o tom případu enterprise aplikace, která se náhodně hroutí při paralelním startu ani nemluvím. Ale možná mám jiný slovník a slovo enterprise je synonymum pro: blbě napsaná.
Omlouvat se není třeba. Mě se způsob zápisu nastavení sítě v networkd prostě líbí.
https://doc.heronovo.cz/2017-04-23-nastaveni-site-systemd.html
Je to ini-like, je to dostatečně jednoduché na napsání ručně a funguje to. Na rozdíl třeba od starých network-scripts z rhelu, kde bylo potřeba mít pro každou adresu vlastní soubor (nebo dělat ty šaškárny s číslováním), tak tady pro 30 IP prostě jen zopakuju 30x řádek Address a je to. Nebo sekcí route pro několik statických rout. Bridge se nastavuje snadno, bond taky (a to dost podobně).
S Network Managerem mám špatné zkušenosti, po páté přidané statické routě (přes nm-tui) už to prostě přestalo fungovat (až do restartu os).
Jinak já se snažím minimalizovat počet komponent v systému, tedy pokud je něco součástí systemd a lze to použít, tak to použiju. Nedělám to z lásky k systemd, to rozhodně ne, ale v některých věcech je to prostě jednooký král mezi slepými. Zrovna v případě té konfigurace sítě mě to tak připadá.
Samozřejmě, že dá. Doporučuju si udělat výlet třeba do FreeBSD. Je to příjemné osvěžení. Je to v shellu, skripty jsou krásně přehledné, rc skripty služeb jsou na pár řádků. Jde to.
To by mohlo vysvětlit složitost systemd
Tak složitost systemd je dána především tím, čeho všeho chce dosáhnout. V podstatě místo dlouho běžících programů (spuštěných jednou při bootu) jak bylo zvykem doposud, chce udělat systém postavený na velmi malých komponentách, které se budou spouštět v reakci na události. A systemd má prostředky na to, jak toho dosáhnout, včetně třeba mountů. Takže lze mít desítky aplikací, každou s vlastním oddílem pro data, který se připojí až je potřeba, tj před startem toho programu, který se nastartoval v reakci na nějakou událost. A toto celé mít třeba zavřené v konkrétním nspawn kontejneru. Lze to, v idle stavu se používá minimum prostředků a v provozním stavu se používá jen to, co je potřeba.
Jenže je tady několik problémů. Jednak nikde není (nebo ke mě se to alespoň nedostalo), uvedeno, čeho přesně chce systemd dosáhnout (takže cíl je potřeba jen odhadovat z toho, co je zrovna k disposici a jak jsou ty komponenty postavené) a podstatnější problém je ten, že chce změnit a totálně obrátit zavedený systém, který je postaven na zcela jiných základech.
Já osobně (ač jsem velký kritik systemd), nemám nic proti změně konceptu na událostní. Hromada malých komponent, aktivují se na jednotlivé události, lze dosáhnout vysoké paralelizace. Ostatně, spousta systémů se takto dávno navrhuje. Ale mají si to udělat na svém vlastním písečku. Mohli mít vlastní OS a představit vlastní konkurenční koncept.
Záleží, co po tom chceš.V principu to není složitý
Mám pro embedded věci (Cortex M) něco podobnýho, požadavky byly:
- Napsáno v C
- Modul je definovaný vyplněnou konstantní strukturou
- Umí init, start a stop modulu
- Umí modulu poslat konfiguraci přes void* pointer
- Umí zpracovat staticky definovaný závislosti na modulech (= uvedených v popisovači) - při initu a startu mají přednost závislosti, při zastavení ten modul. Funguje to rekurzivně.
- Reuse modulu - na jednom modulu jich může záviset několik, při zastavení uživatele modul pokračuje, dokud ho někdo chce využívat. Pokud už ho někdo používá, start se neopakuje
- Podpora několika instancí modulu
- Zvládne dynamicky přidávat a odebírat závislosti podle konfigurace modulu
- Init probíhá paralelně pro několik modulů (protože třeba Ethernet startuje 20ms a za tu dobu můžu nahodit něco dalšího)
- Počet modulů omezený jenom velikostí dostupné RAM
- Dokáže zachytit a reportovat chyby operací
- pro každý modul si pamatuje sekvenci, co má dělat, takže můžu zadat init a start bez toho, že bych čekal na konec initu.
- Funguje s FreeRTOSem
Sakum prdum včetně dokumentace v Doxygenu s příkladama užití ... 1227 LOC. A zatím jsem nepotřeboval timeouty, takže to by bylo dalších cca 20 LOC.
Implementace k modulu přidá asi 50 LOC (šablona, reálně v ní ručně měním 5 LOC) + přidávám implementaci 1-5 funkcí podle požadavků na modul, kde je vlastní start (= například povolení přerušení od HW), stop(= například povolení přerušení od HW), init (= například uvedení GPIO do definovanýho stavu po startu), parsování setupu (= přetypování void* na strukturu s parametry a nastavení modulu) a zpracování dynamických záležitostí (například seznamu modulů pro zastavení při výpadku napájení). Ale tohle je standardně součást aplikací, jenom dostanou příslušný signál (v mým případě voláním funkce přes pointer).
U OS typu Linux by tam popisovač nebyl binární konstanta, ale šla by do RAMky a přibyl by parser popisovače modulu ze souboru.
A uz systemd vyresil tu "featuru" ze kdyz ve fstabu bude mount navic napr. preklep v cisle partisny nebo disk ktery se odpoji a komp rebootne, tak
- se ceka 1.5 minuty (nebo vice) zda se nahodu disk neobjevi (jako WTF #1, cekani na zazrak??)
- nespusti se jine sluzby, napr. ssdh (WTF #2, potrebujete navstivit stroj fyzicky kvuli preklepu ve fstabu?)
Dokud bude existovat alternativa, systemd ke me nesmi. Nervy mam jen jedny :)
Nahlasil si to?
Stava sa, ze to niekto poriadne nedomyslel(myslel len na seba a svoj use case alebo to prehnal s opatrnostou) a takato feature je na svete.
Stretol som sa niecim podobnym pri smb/cifs protokole, kde v jadre, ktore pouziva Debian Wheezy niekto zmenil timeout zo 60 sekund na 5 minut. Bol to pre mna sok, ked uz aj tych 60 sekund je podla mna zbytocne vela. To ti bol zazitok najst kde je pes zakopany, kedze cakat v pripade vypadku siete 5 minut bolo pre nas neakceptovatelne. Trvalo mi to dost dlho najst v hlbinach internetu jedno vlakno, kde sa na to jeden chlapik stazuje, vyvojar mu vysvetlil ako si to vie poriesit a, ze v buducim jadre to bude znovu defaultne 60 sekund(akceptoval, ze tych 5 minut je prehnanych). Neumyslena feature/chyba, ktora by bola v jadre asi dlhsie keby sa neozval.
Malo to aj pozitivny dopad. Naucil som sa toho dost o fungovali smb/cifs protokolu v linuxe a oprasil kompilaciu jadra.
Aha, takže za problémy systemd můžou vlastně vývojáři aplikací, protože nepoužívají jeho komponenty, protože kdyby je používali, stane se jejich aplikace závislá svou funkčností jen a pouze na Linuxu se systemd, ostatní systémy ať už Linuxové s jinými typy initů či jiné *nix like systémy mají smolíka, protože prostě Lennart chce :D
Taky je na místě se zeptat, proč by mě jako vývojáře měli autoři nutit mou aplikaci předělávat způsobem, který znamená, že bude mít problém na jiných OS než Linuxu se systemd, obzvlášť, když moje aplikace normálně do té doby fungovala napříč *nix like systémy a napříč různými inity.
Další věcí je, že spousta věcí v systemd nefunguje tak, jak by fungovat měla, resp. jak je deklarována funkčnost.
Taky je dost blbé, že systemd si sebou tahá spoustu služeb, na které jsou zavedené alternativy a často nutí jejich užití, přestože uživatel má své důvody použít službu jinou.
A úplně nejpitomější je způsob řešení hlášených bugů u systemd, kdy se jasné chyby prohlašují za vlastnosti, místo aby se opravily.
A tak by se dalo pokračovat.
"Taky je na místě se zeptat, proč by mě jako vývojáře měli autoři nutit mou aplikaci předělávat způsobem, který znamená, že bude mít problém na jiných OS než Linuxu se systemd, obzvlášť, když moje aplikace normálně do té doby fungovala napříč *nix like systémy a napříč různými inity."
Dobrá otázka. Stejně tak se dá zeptat na to, proč tě tlačí do používání IPv6 místo IPv4, USB místo UARTu, DP nebo DVI místo VGA, GUI místo konzoly, SSH místo Telnetu,....
"Další věcí je, že spousta věcí v systemd nefunguje tak, jak by fungovat měla, resp. jak je deklarována funkčnost."
Tak jednoznačně největší bug systemd je ten, že se nadá ani najít, ani popsat. Za poslední rok jsem tenhle argument četl v diskusích tisíckrát, ale nikdy tam nebylo jednoznačně řečeno, co a za jakých okolností je blbě. A navíc tam je ten nepolapitelný bug "mnohokrát" :(
Popravdě, tenhle argument už mě dost nudí.
"Taky je dost blbé, že systemd si sebou tahá spoustu služeb, na které jsou zavedené alternativy a často nutí jejich užití, přestože uživatel má své důvody použít službu jinou."
Pod jakou licencí že je systemd, že se nedá forknout a opravit, aby fungoval s náhradou? A proč, pokud to jde, nikdo neměl motivaci to udělat? Pokud je ten důvod kašlat na některý součásti systemd legitimní pro víc lidí, tak by to přece dopadlo jako s OpenWRT/LEDE, KODI/OSMC, ...
"A úplně nejpitomější je způsob řešení hlášených bugů u systemd, kdy se jasné chyby prohlašují za vlastnosti, místo aby se opravily."
No to se nediv. Představ si, že standardní desktop by byl takový, kde na ploše může být jenom jedno maximalizovaný okno a vytvořil bys desktop, kde se dá okno zmenšit a může jich na ploše být několik. A dostal bys bug report od Pepy, že když zmenší okno, je vedle něj vidět kousek toho okna, co je za ním. Co bys Pepovi odpověděl? A co bys mu odpověděl, kdyby už byl tenhle týden 50., kdo tě s tím otravuje?
A nezapomínej, že "jasná chyba" v lamštině znamená "funguje to, ale nezvládnu to ani pochopit, ani použít". Tak ať si tě někdo nesplete s lamou :)
Dobrá otázka
To jsem moc rád, akorát odpovědi (ani dobré ani špatné) se nějak nedostalo... :D A v těch otázkách vašich:
Stejně tak se dá zeptat na to, proč tě tlačí do používání IPv6 místo IPv4, USB místo UARTu, DP nebo DVI místo VGA, GUI místo konzoly, SSH místo Telnetu,....
...je jedna zásadní chyba: nikdo mě netlačí do používání IPv6, používám si skvěle IPv4, nikdo mě netlačí do USB, používám si vesele UART, to samé VGA, to samé konzole a telnet. Nikdo mě do toho netlačí, což u systemd neplatí. Ten do toho tlačí a navíc věci, které fungují jinak rozbíjí = je nekompatibilní s ostatními, což by nevadilo, kdyby aktivně nebránil užívání alternativ, jak to je ve světě Linuxu a FOSS zvykem.
Popravdě, tenhle argument už mě dost nudí.
A mě zase nudí, jak někteří bugy systemd popírají jako by nebyly,
Pod jakou licencí že je systemd, že se nedá forknout a opravit, aby fungoval s náhradou
Co to má co dělat s licencí? On je problém v tom, že alternativ je dost, ale je dost bráněno jejich použití, tento fakt přehlížíte úmyslně nebo jen z neznalosti?
No to se nediv. Představ si...
Představit si dovedu leccos, akorát nevím proč bych to dělal, já se bavil o způsobu řešení bugů tak, že se to prohlásí za featuru, místo aby se to opravilo. Takže raději si představím, jaké to bude, když by se to opravilo, než nějaké smyšlené fantazie...
Na poslední odstavec nemá ani cenu odpovídat, argumentum ad hominem - shazujete se tím na lamu sám.
uz je to tady fakt dlouho, to musi byt nemocne by design, ikdyz myslenky systemd se mi libi. ja se porad lamu, jestli svoje gentoo servery preklopim na systemd, mam 15 experimentalnich masin, jsem primarne vyvojar... co to tu ctu tak fakt nevim.
mate nekdo zkusenost s mesos, nebo jeho extenzi dcos nad systemd?
Dlouho sme měli koňa. Nebyly s nim starostě, až pak jednou zdechnul, tatik už druhého nechtěl, že žere aj v zimě. Včil máme traktor, ale těch problémů! Třeba sem se musel naučit měnit olej a jednou jsem dokonce měnil vstřikovací trysky! Ten traktor je nemocné už od návrhu, tohle kůň neměl...
Ale jinak mě to nepřestává fascinovat. Primárně vývojář s 15 experimentálníma mašinama prostě experimentovat nebude, protože se na jakémsi fóru dočte, že má někdo s nějakým kusem software problém.
no sorry frajirku, ale oba dedove meli kone a dnes mame traktory a je to vic bezudrzbova zalezitost. mas hezkej sloh, ale uplne mimo realitu , ackoli ja jsem se nejak vydal jinou inkarnacni cestou...
asi ses o kone nikdy nestaral. ja mluvim o tom, ze kdyz kdyz prevadim myslenky do navrhu, tak to delam durable, pokid je moznost nejakeho stucku, tak navrhnu protistuckove funkce, kdyz heozi, ze nedochazi k auto restartu, tak dam do systemu bud doublu check, nebo to navrhnu tak, ze k tomu nemuze dojit....
dalsi vec, proc si myslim, ze jakejkoli monolith je spatne (napsal jsem monolithy pro generovani a zpracovani faktur, kde nikdo nikdy nenasel chybu, ale urcite tam byla). zacinal jsem na plc systemech ve skodovce, programovali jsme montaz fabie back in 2000. chyba kazdych 10-20 minut, reseni zabralo 1-5 minut, po pul roce chyba za 3 dny, reseni 1-3 hodiny. tenhle stav ma samozrejme matematicky zaklad ve slozitosti. nechci uplne rikat ze systemd navrhli blbe, ale rozhodnuti monolithu je spatne, schovavas do nej radove vice chyb nez do mikroservices. traktor je spis jako microservice, upadnou mu kola, ale motor porad facha, koni upadnou nohy, a umre. chapes? to jsou fundamentalni veci v designu, ackoli jsou funkce vicemene stejny, jedna nebo jina cesta te vede do ruzne velkeho pekla... make your choice.. nevim, jestli si studoval navrh softwaru, ale jestli ne, tak bys nejdriv mel, nez cist blogy...
v praci jsem se samozrejme se systemd uz taky setkal, potvrzuji, ze ty error logy jsou nekdy uplne k hovnu nebo zadny.'. nejsem admin ale mam omezeny nekdy plny sudo a serveru mame asi 100, ale tam se vyhybam delat admina
ps: delam architekta mikroservices a ai
Odpověděl jste si sám, ačkoliv ty příměry jsou mimo, jak je obvyklé, když se softwarový architekt pustí do "automotive" porovnávání. Mě je traktor bez kol k ničemu i kdyby stále běžící motor plnil Euro 6 a myslím si, že se na tom shodnu s většinou sedláků.
Systemd není monolit, samotný init je velmi malý. Zbytek argumentace taky nechápu, tento init umožňuje restartovat službu za podmínek daných autorem služby, nikde není dané, že se služba musí restartovat. Máte volbu. Stejně tak máte možnost spustit služby po sobě v pevně daném pořadí. Běžně to nikdo nedělá, ale jde to.
Kupodivu existují lidé, kteří dokáží opravit chyby systemd (a abych použil Váš vychloubačný přístup, systemd mám nasazený na desetitisících zařízení, které mají společné snad jen to, že musí běžet bez dozoru a problémy samočinně hlásit) v řádu hodin, ale to není věcí systemd nebo software Vaší montážní linky, ale znalosti návrhu a implementace opravovaného kódu.
Výše jsem narážel na to, že dostanete traktor místo koně a divíte se, že nefungují postupy pro chov koní běžné. U vývojářů, architektů, ap. mě takový přístup překvapuje, nic víc. A neberte si to osobně, lidí, kteří trpí předsudky na základě toho, co si přečetli na kdejakém blogu je i mimo IT víc než dost.
A nakonec, journald je velmi dobrý systém logování, ale spolehlivě ho dokáže rozhodit nesmyslně nastavený čas v okamžiku startu. Možná jako architekt oceníte možnost napsat si vlastní log storage, třeba někam do NVRAM, takže uvidíte i předsmrtné logy, které by jinak zmizely v cache.
Ja se fakt nevychloubam, nebo jsem tak zaslepen sam sebou, ze jsem si toho nevsiml :-) Taky jsem se nedivil, ze by byl rozdil mezi konem a traktorem... Sam jsem si rozhodne neodpovedel, resp. nedostal jsem se k odpovedi.....to jsou nejake tvoje vnitrni preludy(asi bezis na systemd :-) )....
Ad: softwarový architekt pustí do "automotive", ja jsem odrostl na automotive asi uz jako dite (ale jinak gefanuc a simatiky) a az pak jsem se zapletl s jinym balastem a skoncil primarne na Jave, okrajove C a Pythonu.. a samozrejme Gentoo, ostatni distribuce krome Debianu povazuju za zbytecne (mozna moje zaslepenost).... ale zpet k systemd
On na nizke urovni take nasleduje mikroarchitekturu, jde o nejakych cirka 70 knihoven jestli se nepletu v plne show, ale me to prijde derave jak reseto, protoze veci, ktere hlasa resit jsou nestabilni, a tech nestabilit je tam na muj vkus hodne na to, abych to mel na produkci (tohle je mozna predsudek, muze byt). Spousta uz je jich opravenych, ale tim, ze je to komplexni system, tak ty opravene jen umoznuji nekterym skrytym byt nalezeny (analogie na slozitosti viz predchozi prispevek). Me to trochu prijde jak kdyz navrhuju tank, ktery projede zdi, ale kdyz najede na klacek, tak se rozlomi vejpul, jsou tam nektere veci (z github issues), ktere me k tomuto vedou, aktualne:
707 open a 2341 closed
z toho
70 bugs open a 437 bugs closed, ale oni pouzivaji skoro 100 labelu, takze nevim, co vlastne je a neni chyba systemd jestli jen bug label, nebo i dalsi....
Takze takhle se ten system ma aktualne. Ja uz vim na co si narazel, ze jsem byl vychloubacny(ted mi to doslo, protoze jsem to chtel zase zminit :-)). No ano, to se mi podarilo ale uz nekolikrat, ze jsem napsal netrivialni software, ve kterem urcite byly chyby (i ja jsem o nekterych vedel, ale vzdy se samozrejme hrozim tech, o kterych nevim), ale fungoval a uzivatel zadne chyby nezaznamenal. Proto proboha pisu unit/integracni a automatizuju i user acceptance testy (simuluju scenare, ktere bude uzivatel provadet) a jen potom to vypustim do sveta. Sorry jako, ale at uz to je velkym soustem, nebo nekvalitnim testovanim, ja opravdu neznam systemd management a historii taky nic moc. Ale ty cisla ukazujou, ze to neni koser a je jedno jestli na tom REDHAT maka a fixuje. Zvlaste pokud na tom REDHAT tak pracuje, tak bych prave cekal, ze se spousta tech chyb odchyti, taj mi to prijde, ze to proste namastej, vypada to dobre, tak to vysmazime ven a uvidime. Mozna jsem trochu pokriveny (v dobrem slova smyslu) prave z automotive. Pokud bych tam neco podobneho vypustil na svetlo bozi, tak se mi urve karoserie z transferu, nebo nedej boze vytlacim celou karu i se skidem z vytahu ve druhym patre a necham ji jumpnout na podlahu.... IT IS NOT ACCEPTABLE - a proto je neakceptovatelny pro me i systemd, tak jak je ted a uz je tak pekne dlouho... end of story
Realny problem: chci na svoje GPU masiny ted stejne instalovat DCOS(protoze uz chci instalovat cpu/gpu aplikace pouze ve forme docker imagi) a lepsi nastroj jsem nenasel (krome mozna kubernetes, ale dcos je generictejsi), na laptop zase miraclecast abych mohl delat prezentace pres wifi na projektoru/televizi, oboje systemd dependant.. Druhy zmineny se pokousime zmigrovat na openrc v ramci Gentoo komunity.
Takze ja se systemd nevyhybam, a diky nekterym vecem, na kterych delam je to jedina moznost, jestli nechci pracovat na portovani (coz nechci), ale nepovazuju to krome krasnych myslenek za kvalitni produkt, no way, sorry jako. A jestli ty jo, tak nevim ty vole, cim se zivis.
Je to furt dokola. Počty chyb z bugzilly bych jako argument... Nebylo by lepší podívat se, co se za těmi chybami skrývá? Systemd používá integrační testy ap. Možná byste mohl vysvětlit, co Vás vede k závěru, že tomu tak není, když sám přiznáváte, že neznáte způsob vývoje systemd. Čísla neukazují nic, naprostá většina bugreportů je typu "tady jsem něco udělal a ono to dělá něco jiného než jsem si myslel, že to bude dělat", týkají se kontejnerů, seats, zkrátka to, co System V vůbec neřeší. Chyb, kdy to dělá něco jiného, než je dokumentované, je minimum (sám jsem zatím na žádnou nenarazil, takže pro mě (a zákazníky) je to software bez chyb).
Já Vám, ani nikomu dalšímu systemd necpu, jen se ptám, co Vás vede k tomu, prohlásit cizí práci za zmetek na základě informací z blogů a fór.
K reálnému problému: oboje je systemd dependant protože, seats, device management, atd. Tohle neřeší init jako takový, ale další moduly systemd. Nakonec sám píšete, že se pokoušíte o migraci, takže musíte vědět, co za Vás systemd dělá. Přeju Vám, aby ve Vaší reimplementaci bylo co nejméně chyb ;-)
Proste vyprodukovat neco, co ma v sobe minimalne 500 veci oznacenych za bugy a cpat to do produkce (je to managovane lidmi ze systemd, oni delaj labely, to normalni github users nemuzou). Jako Oracle, Postgres databaze ma v sobe taky tunu bugu v produkce, tj. je to battle tested poradne az kdyz se to dostane do ruky, ale ty vole to je taky komplexni system jak krava.
Nepochybuju, ze na tom delaj dobry mozky, ale cetl jsem detailni clanky ukazujici proc je systemd superior, a take proc neni(at uz systemd fanatiku, nezazaujatych, nebo hateru :-) ). Ten impact je enormni zejmena i na outof Linux world -> Unix a BSD arena. Aplikace sou uz nove napsany na systemd a ....
Ale uz toho nechme, vse dobre...
No tesim, az zavitam na nejakej systemd festival, hlavni host vecera Lada Michl :-)))
Ale k zakladni otazce celeho threadu: Dělá systemd Linux více složitým, náchylným k chybám a nestabilním
Odpoved: Ano dela, ikdyz to nemusi byt zpusobeno primo systemd :-))
Jak se ta komplexnost měří? Na počet řádků asi ne, PostgeSQL, teda Postgres, vyvíjený od roku 1986 jako nástupce Ingresu, který má za sebou čtyři dekády a furt sou v tom chyby... No nic, 3x tolik řádků kódu v C souborech a to akorát ukládá data a hledá v nich (teď sem to přehnal a jistě to schytám :-))
Úplně po lopatě: na detailní články matlat a podívat se do kódu :-)
A k základní otázce: Ano, systemd dělá GNU/Linux více složitým, protože je psaný za účelem řešení problémů složitějších než prosté spuštění procesu. Za mě naprosto stačí 2 inity, systemd a busybox/init/init.c
Aha, argumentace počtem bugů. To už docela smrdí statistikou. Pamatuju se, jak přednášející ve statistice na první přednášce začal: "Teď si vystupňujeme slovo LEŽ. Lež, odsouzeníhodná lež, statistika".
Čísla jsou o ničem, pokud nevíš, čeho se týkají. A to z jednoho čísla nevíš nikdy. Víš, že třeba
- můžou používat CI a pokud někdo přidá soubor se zdrojákem, ale nepřihodí ho do commitu, sám se mu přidělí tiket na opravu bugu hned, jak to odešle? git add, git comit, fixnuto. Ale v té tvojí statistice to zůstane.
- můžou používat unit testy. A něco se rozbije ve vývojoví verzi, která ještě ani není v RC. Vyskočí bug report, ještě ten den je fixnut a nedostane se dál, než k tesťákovi. Ale tobě straší ve statistice chyb na produkci.
- Jde o bug, ale ve spolupracujícím modulu, kde tvůj soft funguje třeba jako wrapper. Vytvoříš tiket pro ten modul, dáš odkaz do svýho (protože chybu je potřeba opravit, ne zamaskovat) a zavřeš to, protože ve tvým softu chyba není. Bum, Jech má další argument, i když tam ta chyba není.
- Uživatel něco nepochopí podle dokumentace. v SW je to korektně, žádný bug. Upřesní se dokumentace, aby byla jednoznačná a do SW se nesahá. A tiket se zavře, jenomže pro Jeca i tohle znamená, že je ten soft děravý.
A takhle bych klidně vycucal z prstu 50 dalších důvodů, proč tam může být tolik tiketů bez toho, že by v SW bylo cokoliv zásadního blbě. Takže - racionální argument místo statistiky, které sám nerozumíš, by tam nebyl?
Ty si pletes issue vs bug, takze proti me argumentujes jeste vetsim blur efektem, nez ja(a ja jsem tu chtel pouzit pouze hruba cisla viz nize). Issue je obecnej record a bug je label, a ja jsem jen vytahnul bugy(tj. problem tam je). jinak tam maj 134 issue labels, priznam se, ze nevim k cemu vsechny jsou...
Github systemd pouziva exkluzivne pouze pro bug reporting a novy ficury a to pouze pro 2 posledni verze. Pouzivaj travis CI, ale nemaji tam auto issue generation, tj. muzou to mit vedle, ale ok, uznavam, ze nevim co delaj, kdyz CI zarve, ale zda se mi, ze to perou pres Fedoru (jak jinak)
Primarne 3000 issues je na fedore a 200 na debianu(nerozlisuju, jestli je problem v systemd, nebo jinde, nerozlisuju jestli jsou to vsechno bugy).
Ty se me snazis argumentovat na zaklade toho, co pisu, ale ja se tam kouknul a prohlidnul jsem si i jejich testy, a projel jsem si reporty. Ale ty ses tam evidentne vubec nekoukl(preludovy predpoklad pouze), protoze si nic neuvedl na pravou miru... jen tupa reakce na me, kdo si to cele prolezl a kouknul se na nektery bugy v detailu skrz celej arzenal projektu systemd vcetne test casu....chapes, jak ses povrchni vole? :--)))
Zaver: Ano, pouzivam hruba cisla, abych tim hrube ukazal, ze systemd je tlusta krava a ackoli je tu tak uz 7 let, tak ji bude jeste trvat nejaky cas, nez se napase na moji louce :-) beres to? :-))
Je pravda, že systemd se někam hrubě nehodí. My např. s oblibou používáme hodně odlehčenou variaci na téma Docker (takový chroot s namespaces, vlastní síť, procesy atd.), jednotliví uživatelé VPN si v tom hoví, aniž by byli vzájemně rušeni. Systemd v tom dělal slušný bordel, plně tak chápu, že někomu pije krev. Na klasickém serveru v něm ale nevidím sebemenší problém, vždy fungoval "bez ztráty kytičky", nevšiml jsem si, že by to bylo nějak nestabilní.
