Já si nemůžu pomoct, ale mně to pořád připadá jak lépe organizovaný nepořádek...
Proč nepořádek? Deklarativní popis služby je jenom nastavení nějakých proměnných. U systemd je to v nějakém .ini formátu, u toho, co jsem ti ukázal, je to v shellovém formátu var=val. V čem ti přijde tak zásadní zlepšení shell->.ini? Mně to přijde jako spíš zhoršení, protože v shell formátu si může - pokud budu chtít - načíst hodnoty libovolným spuštěním příkazu. Třeba wgetem z konfiguračního serveru. U systemd to neuděláš. A kdyby to lidi chtěli, tak se zavede další proměnná "ReadConfigFromHttp", pak se zjistí, že k načítání přes HTTP potřebuješ http knihovnu, tak se http knihovna vloží do binárky PID 1 a následujících deset let se v ní budou nacházet bezpečnostní chyby, umožňující eskalaci na roota. Ale hlavně, že to není nepořádek
Tak ony jsou 2 argumenty proti systemd - jeden je proti architektuře ve stylu "můžeme to spouštět ze skriptů a taky to funguje" a druhý "systemd je blbě napsaný software se spoustou bugů a neschopnýma (nebo všeho schopnýma) vývojářema". S druhým argumentem souhlasím, ale ten první nechápu. Pořád.
Jenže ten první argument zní spíš "proč vrtat do něčeho, co funguje?" - každý admin se na změnu dívá stylem "máme silný argument, proč změnu dělat?" a ne "Máme silný argument, proč změnu NEdělat?"
Editovat si init skripty to zavání průšvihem. Nebo snahou administrátora nebýt vyhozen, protože se v tom nikdo jiný nevyzná.
Ale blbost. Buď je ta oprava triviální, nebo si třeba uděláš jiný startup skript bokem. Kařdopádně oboje děláš nějaký configuration managementem (puppet, ansible, salt...), takže je to změna jako každá jiná.
Konkrétní příklad: triviální chyba ve startup skriptu služby v Ubuntu. Ticket bez opravy visí v bugzille rok:
https://plus.google.com/+MiroslavPrymek/posts/TAYTy8DHMLq Co myslíš, že má admin udělat? Opravit to a mít stabilní server, nebo rok čekat, až se někdo v Canonicallu rozhoupe?
Tak ono taky záleží na tom, co chceš logovat. Nevím, co je stupidního na tom dělit to pomocí \n, když víš, že v té zprávě ten enter nebude.
Jenže to nikdy nevíš. Logované zprávy typicky citují nějaká vstupní data, kde se \n může objevit i když to nečekáš. A celej logging se ti takovou blbostí může rozesrat. Spolíhat na to, že se ti nikdy v logované zprávě neobjeví BĚŽNÝ znak, je hloupost. Nemluvě o tom, že třeba stacktracy \n vždycky obsahují - a nechceš mít jeden stacktrace rozdělený na dvacet samostatných zpráv. Čili minimálně pro jakýkoliv jazyk, který v případě chyby vyhodí stacktrace je to no-go.
Můžeš si to klidně tisknout v jsonu a pak si to někde v log managementu naparsovat. Popravdě syslog zas tak špatný není, máš tam severitu a to je vlastně asi nejdůležitější. Ale ono je typické takové to "jsem na tomhle systému, z nějakého důvodu mi neběží X, co se stalo". A pokud to něco vypsalo, přes journalctl to snadno najdeš.
Však jo, syslog je v pohodě (když máš nad ním nějaký ten strukturovaný formát). Ale opakuju otázku: jaké strukturované formáty podporuje systemd-logger, pokud aplikace loguje na stderr? Pokud chci jeho logy dostat do rsyslogd, jak mi je předá? Rozdělí podle \n? To ale nechci. Mám možnost ho donutit k jinému chování? Kolik hodin/dní/týdnů to budu zjišťovat? Kolik hacků budu muset udělat, abych dosáhl chování, které už jsem měl odladěné? Kolik hodin/dní/týdnů bude nalezené nové řešení fungovat, než se někdo v upstreamu rozhodne to změnit?
Chápej, tohle jsou otázky, které adminy zajímají. Ne nějakej přiblblej rychlejší boot a "čistější" popisy služeb.
Pokud tím myslíš z důvodu věcí, které systemd přináší, tak teda nesouhlasím, pro mě to teda výrazný krok dopředu je.
No ale ještě jsi neuvedl jedinou věc, která by už dávno nebyla vyřešená i bez systemd a která by zároveň výrazně pálila výrazné množství adminů...
145 Odpovědí
49143 Zhlédnutí