Názory k článku Nebojte se systemd: co to je a co umí?

Budete mít možnost volby, zda bezbolestně změnit os a systemd s tím, že pro aplikace se nic jakoby nezmění, a nebo vyměnit aplikace.

Aha. To jako za dvacet let bude v OS porad uplne stejny format binarek a urcite i uplne stejne verze knihoven, aby se to nemuselo rekompilovat. Nebo budeme vsichni mit pocitace narvane jadry a RAM do takove miry, ze to vse pojede v interpretovanem jazyce nebo s nejakym just in time kompilatorem?

To samé třeba v autonomních automobilech zde na Zemi. Bude neúnosné spravovat sw automobilů na dálku s tím, že budou v provozu modely za 20 let s různými verzemi OS. A předpisy se pro ně budou měnit co půl roku, jak známe byrokracii.

To chci videt. OS v novych autech bude desetkrat tak velky, nez ten v tech 20 let starych. A nebude tam ani pamet na ulozeni novych predpisu. Ono se staci podivat, jak do rok stareho telefonu uz nejde narvat novejsi verzi OS a poku jde, tak jen pokud ma clovek obzvlaste pevne nervy, aby vydrzel nekolikaminutovou odezvu, protoze tomu "staremu" telefonu schazi 8 jader a 64 GB RAM, aby to utahl.

Myslim, ze byste se mel vice informovat a do te doby, nez budete opravdu danemu tematu rozumet, spise klast zvidave otazky a ne psat vybusne a zbytecne vyhrocene vety. To nikomu nedela radost cist takovou diskuzi.

Proč by měl jakýsi nedefinovaný "zbytek" polykat systemd? Ten spolkne jen to, co umožní spuštění vyžádaných a nezbytných systémových aplikací. Zásadní otázkou je udržet objem těch systémově nezbytných v omezení nedovolující b(l)obtnání. V archu si mohu nastavit vše, co chci a považuji to za rozumné i s ohledem na systém.

Opravdu nevim, proc by nekdo zacal vydavat updaty jen proto, ze mame IoT. Updatuje se prece koupi nove televize nebo mixeru a nez se koupi updatuje, bude lednicka v botnetu A, zachodove splachovadlo v botnetu B a mycka na nadobi v A a C. Nejhorsi bude pracka, protoze ta bude napadena malware, ktery pri programu na prani vlny a pri prani pri nizkych teplotach nastavi 90°C. Vyrobcum to bude jedno, protoze podpora konci mesic po zaruce.

Ostatně v hlavě to máte taky tak, základní OS - podvědomí řídí činnost vašeho organismu, přiděluje například kyslík jednotlivým orgánům, a vědomí (systemd) určuje, co s tím organismem podniknete :-)))

Kdyby pridelovani kysliku ridilo podvedomi, asi bychom se prilis vysokeho veku nedozili. Pokud systemd ma byt jakymsi podvedomim OS, tak to s Linuxem vidim blede, protoze prave podvedomi je zodpovedne za hafo problemu, kterymi lidmi trpi.

Podvědomí člověka určuje všechno a už je dokonce dokázané, že rozhodnutí které zdánlivě dělá člověk, je několik (asi) milisekund před tím nadiktováno podvědomím.

Není to dokázané. To jsou pouze závěry lidí, kteří jsou bohužel více filozofové a humanisté než přírodovědci. To je totéž, jako kdybych za vznik události považoval dobu, kdy se informace objeví na monitoru a potom bych byl velmi překvapen, že se ještě před tím cosi děje (dekódování obrazové informace v monitoru, zápis do framebufferu na grafickou kartu, zavolání printf, potom přijde někdo nový a za vznik myšlenky označí právě to volání printf a je opět překvapen, že tomu printf něco předchází. Přitom to větvení, které v konečném důsledku vede až k tomu výpisu na monitoru mohlo dojít někdy miliony instrukcí před tím. A často ani to větvení nelze označit za vznik myšlenky.

Je jedno video (asi na matfyzu), kde nějaký filozof vypráví o času a důsledky pro vědomí, důsledky pro současnost apod. sem tam se opírá o závěry vědy. V diskusi na konci ho přítomní kvantový a relativističtí fyzici trochu uzemní s tím, že ty koncepty, na kterých on vystavěl svou přednášku vůbec nelze vykládat takto.

V těchto věcech je nutná spolupráce mezi mnoha obory a to, že jeden signál na eeg předchází jiný signál ještě neznamená nic o kauzalitě. Navíc se to komplikuje tím, že mozek umí události posunout do minulosti (např. známý efekt, když otočíte hlavou a podíváte se hodiny - někdy máte dojem, že první sekunda trvá o dost déle, než další - je to způsobeno tím, že mozek zpětně nahradil "rozmazaný obraz" během otáčení hlavy prvním "snímkem" hodin). Motion blur očí ve skutečnosti vůbec nevnímáme. (Ne že by to nešlo, ale je třeba se aktivně na to soustředit.)

Zdůvodňovali to tím, že mozek impuls upraví tak, jak má zafixováno podvědomě a z toho se tvoří vědomí. Jedno je jisté. Z křišťálové koule to neleze a mozek, resp. podvědomí, je tvořeno nastavením neuronů a z toho taky vylézají vědomé myšlenky, takže z čeho by to pak pocházelo než z individuálního nastavení mozku?

No to jo, ale slyšel jsem interpretace, že to znamená, že člověk nemá svobodnou vůli, protože se myšlenka tvoří ještě dřív, než si to člověk uvědomí. To je nesmysl, protože i to "uvědomování si" nutně vyžaduje aktivitu neuronů a tedy začíná ještě před tím, než si to člověk uvědomí. Na to není nic divného a překvapilo mě, jak si to někteří lidé vykládají. Prostě to, že se na eeg objeví aktivita 200ms před tím, než si něco uvědomím, to neznamená, že mi to nařídilo podvědomí a já jsem jen jeho otrokem. Je spíš otázkou, zda tyto pojmy mají vůbec nějaký smysl, případně jak je vůbec definovat.

Z Debianu systemd jeste jde vyndat. Otazka je, jak dlouho jeste a otazka je, jestli Gentoo vydrzi napor mainstreamu.

Jiste. Ja jen nechapu, proc systemd jeste nemaji v BSD a jinde. Vzdyt je to prece tak skvely init, ktery navic ma tu uzasnou vlastnost, ze si muzou napsat i vlastni verzi, pokud zachovaji API a bude to fungovat tak dlouho, dokud Poettering neprijde s modifikovanym API.

Koupil jsem si nový auto. Furt má tři pedály, volant a šaltpáku.

Auto se systemd ma pedalu devet, saltpaku nema, misto volantu ma dvoje riditka, z nichz kazde ovlada jedno kolo. Radi to samo a pedaly se mackaji vzdy dva az tri najednou. To muze byt dost problem, protoze vetsina lidi ma jen dve nohy.

Kdyby kritici využili energii, kterou vynakládají na kritiku systemd a na osobní ataky na Poeteringa k tvorbě lepšího initu, tak si systemd neškrtne.

Tenhle argument slýchám už dlouho, když se vám to nelíbí, tak si napište lepší init. No, co tahle třeba zachovat možnost použít původní sysv / upstart / cokoliv? Myslím, že by spousta lidí neměla se systemd takový problém, kdyby měla možnost jej prostě nepoužívat. Nebo si jej používat tam, kde chtějí. Jak vypadala diskuse v Debianu, kdy někteří chtěli zachovat možnost volby init systému, všichni víme.

> Je to hromada práce kterou ovšem nikdo nechtěl dělat, vývojáři z Debianu raději chtěli věnovat úsilí lepší podpoře systemd.

Máš pro tohle tvrzení nějaký důkaz?

Podle mně dostupných informací totiž věc rozhodovala TC, došlo k plichtě mezi Upstartem a Systemd a pro Systemd rozhodl hlas jediného člověka - předsedy TC.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6734

A mimochodem, pro systemd hlasoval i Russ Allbery, který z TC odstoupil a v rezignačním emailu napsal, že v otázce systemd rozhodl špatně a že odstupuje proto, že práce v TC vyžaduje lepší přípravu, než jaké je schopen:

https://lists.debian.org/debian-ctte/2014/11/msg00071.html

No jo, co bys od nej chtel, kdyz je to Rus. ;-)

A ted si predstav, ze jeden hlas rozhosl o tom, ze se v USA mluvi anglicky. Schazelo malo a cetl bys doc k Linuxu nemecky.

BTW, jestlipak Allbery nasledne spachal seppuku motorovou pilou, jak by se v takovem pripadu sluselo?

Hm, asi ano. Zagoogloval jsem a vypada to, ze je to kachna, ktera vznikla nejak takto: http://www.english.illinois.edu/-people-/faculty/debaron/essays/legend.htm

1. Od initu bych jako uživatel čekal

Otázkou je, zda je init tou správnou vrstvou, na které by se to mělo řešit. Máme virtuálky, máme kontejnery, ty si zapněte a vypněte, kdy potřebujete. Případně nevidím problém se relognout z gnome do kde a v terminálu si pustit service httpd start.

2. Není lepší jenom deklarovat "pro db server spusť a, b, c, d. D spusť v okamžiku, kdy a, b a c už běží." a neřešit, ve skriptu pro c, že parametr x daemona a musí být 7?

Tak především žádné takové složité závislosti nejsou v praxi potřeba. DB server si můžete pustit jako uživatel klidně příkazem pg_ctl start -D /data a máte to. Hromada démonů (a s nástupem systemd se to nemění), má ovládátko typu daemon_ctl.

V tomto případě je systemd v nevýhodě, protože zatímto do původního init skriptu byla možnost si vedle standardních start, stop, status apod. přidat třeba configtest. Takže admin příkazem service httpd configtest zkontroloval nastavení a příkazem service httpd reload jej potom nechal zavést. U systemd o tuto možnost přicházíte a je nutné pro kontrolu volat apachectl -t -D cosi ... (což je samozřejmně správné řešení).

3. Jako programátor nechci zabíjet čas psaním skriptu

Tohle čtu pořád dokola. Opravdu je taková zátěž, pro někoho, kdo napíše tisíce řádků kódu pro jeho skvělý program, pozměnit nějaký template? Stejně se s těmi rc skripty nic jiného nedělalo. Napsat akce pro start, stop, hotovo. Stejně se to píše i do systemd unity. Tak jaký je rozdíl. Za život jsem napsal mnoho rc skriptů, stejně tak několik unit pro vlastní potřebu, rozdíl v tom fakt nevidím. Ano, zápis unit souborů je přehlednější.

Hromada démonů (a s nástupem systemd se to nemění), má ovládátko typu daemon_ctl.
Což vypovídá o kvalitě dříve používaných správců služeb. Kdyby poskytovaly potřebné služby, málokdo by měl potřebu psát si vlastní ovladač služby. To, že se to zatím nemění, je přirozené – nikdo nemůže čekat, že s vydáním první verze systemd na něj přejdou všechny projekty a veškerý legacy kód zahodí. Ostatně, stačí se porozhlédnout tady v diskusi, co se děje, když vývojáři Gnome prohlásí, že nehodlají udržovat kód, který s DE nesouvisí, a začnou využívat logind.

kdo napíše tisíce řádků kódu pro jeho skvělý program
Dotyčný je asi dobrý v psaní toho svého programu, ale v psaní shell skriptů bude spíš průměrný nebo podprůměrný. Proč by měl svůj čas ztrácet tím, že bude bastlit nějaký skript, proč by měl svůj skvělý program kazit tím, že pro něj napíše špatný init skript? Jistěže to nakonec nějak splácá, ale má to smysl? Nemohl by ten čas využít lépe?

pozměnit nějaký template? Stejně se s těmi rc skripty nic jiného nedělalo
Pak je ale nesmysl, aby těch pár hodnot bylo schovaných v nějakém skriptu, prakticky se to nedá kontrolovat a testovat, snadno tam omylem uděláte něco jiného, než chcete. Všude, kde to jde, je snaha nepsat jak se má něco dělat, ale napsat jenom co se má udělat a to jak nechat na univerzálním otestovaném programu.

Mícháte dohromady dvě věci. Jedna věc je konfigurace. Ta opravdu může být komplexní a budete ji raději nastavovat přes nějakou management konzoli. Ale není důvod, aby se tahle konzole starala o správu procesu – stačí, když správci procesů předá informaci, co a s jakou konfigurací se má spustit. Díky architektuře systemd pak může mít pořád informace o příslušném procesu a může ho ovládat.

PS: predchozi verze systemd mazala odhlasenym uzivatelum shared-memory segmenty, nova jim dokonce zabiji procesy.
To nevadí, že jste si ani nepřečetl release notes. K nadávání na systemd úplně stačí znát polopravdy vyčtené z diskusí…

Pane Jirsák, říkal jsem si, že nebudu zbytečně trollit, ale na ten váš systemd fanatismus se nedá nereagovat. Myšlenka systemd není z principu úplně špatná, ale provedení je taková katastrofa, že bych zodpovědným jedincům do smrti zakázal práci s výpočetní technikou, včetně chytrých telefonů, televizí, kávovarů a nevím, čeho ještě. Nevím, jaké jsou vaše zkušenosti z opravdového nasazení, moje jsou takové, že poslední dobou systemd může za většinu problémů (pardon, jak by řekl LP, nejde o problémy, ale o vylepšení). Vaše argumenty, jak to usnadní práci, jsou pro většinu programátorů jen žvást. Spousta OSS SW běhá na mnoha platformách, od Win, přes Linux, *BSD, někdy až po opravdové UNIXy (kterých už moc nezbylo). Takže programátor má několik možností - zakouká se slepě do systemd a všechny ostatní platformy odepíše (nebo bude doufat, že se najde někdo, kdo mu bude zpětně systemd věci vykuchávat a upravovat to pro jiné platformy), nebo bude řešit variantu se systemd a bez a nebo se prostě na systemd vykašle a místo zápasu s API, který se mu mění pod rukama raději (jako už 1000x předtím) upraví/vytvoří skript. Mluvit o tom, že například několikrát zmiňované databáze opravdu není možné testovat jen podle běžícího procesu, ale stejně k sobě budou mít vždy vlastní monitoring, to asi nemá ani cenu.

To, že jiné platformy nemají rozumného správce procesů, znamená, že ho nesmí mít ani linux?

Jinak mně je systemd celkem jedno, mně vadí akorát to, když někdo kritizuje věci, které nejsou pravda. Když bude někdo kritizovat SysVinit proto, že někde v diskusi četl, že žere psi, budu mu oponovat úplně stejně.

Mluvit o tom, že například několikrát zmiňované databáze opravdu není možné testovat jen podle běžícího procesu, ale stejně k sobě budou mít vždy vlastní monitoring, to asi nemá ani cenu.
Cenu to nemá. Nevšiml jsem si, že by tu někdo něco takového psal, ale četl jsem jenom pár komentářů.

Tak já si dovolím tvrdit, že kritizuji pouze to, co je pravda a s čím mám osobní zkušenosti - systemd je stále se měnící nedodělek s nepředvídatelným chováním a nemá v produkci co dělat.
Hlavně nemůžu pochopit, jak mohly velké distribuce na ten krám tak rychle přejít... Jinak jsem celkem v klidu, dokud je SLES 11 podporovanej, dávame ten, až bude nutné přejít na 12, tak se ukáže, jak umí SuSE podporovat zákazníky :D

Což vypovídá o kvalitě dříve používaných správců služeb.

Programy *_ctl nejsou jen o akcích start a stop. Jsou to dálková ovládání master procesu daného démona a řeší mnoho dalších věcí. Bylo by dost divné, kdyby do sebe systemd absorboval dálkové ovládání každého jednotlivého démona.

bastlit nějaký skript, proč by měl svůj skvělý program kazit tím, že pro něj napíše špatný init skript?

Ale no tak... Co je těžkého na tom vzít template rc skriptu a dopsat jeden řádek do start a druhý řádek do stop? Které budou úplně stejné, jako v systemd unitě.

Všude, kde to jde, je snaha nepsat jak se má něco dělat, ale napsat jenom co se má udělat a to jak nechat na univerzálním otestovaném programu.

No to je sice hezké, ale jak u systemd unity, tak u rc skriptu stejně skončíte u toho, že musíte napsat jak se má daný program spustit a ukončit. Ani systemd nemá křištálovou kouli a nevyvěští si, jak má udělat akci (tedy to "co") "prosím zapni mi můj program". Stejně mu tam do ExecStart musíte napsat příkaz na spuštění toho programu.

Bylo by dost divné, kdyby do sebe systemd absorboval dálkové ovládání každého jednotlivého démona.
Divného na tom není nic. Systemd nepřevezme konkrétní ovládání, jenom umožní komunikaci mezi ovladačem a službou. Tím pádem nebude potřeba proprietární apachectl, ale budete moci službu ovládat libovolným nástrojem, který to bude umět. Třeba univerzální konzolí, která bude umět ovládat různé služby (a nebude to dělat nebezpečným voláním konzolových nástrojů na pozadí doprovázeným modlitbami, aby nedošlo k chybnému souběhu).

Co je těžkého na tom vzít template rc skriptu a dopsat jeden řádek do start a druhý řádek do stop?
Co je výhodného na tom psát to do nějakého skriptu, když to mohou být dva řádky v konfiguračním souboru? Navíc u normální aplikace stačí jeden řádek… A hlavně, že je to tak jednoduché a stačí napsat dva řádky na správné místo, to víte vy. Ale autor toho programu to nejdřív musí zjistit – a přesvědčit se o tom, že opravdu kvůli těm dvěma řádkům musí existovat celý ten skript.

stejně skončíte u toho, že musíte napsat jak se má daný program spustit a ukončit
Normální program se spouští tak, že se napíše jméno spouštěné binárky a případně seznam parametrů. Ukončuje se tak, že se mu pošle příslušný signál.

Stejně mu tam do ExecStart musíte napsat příkaz na spuštění toho programu.
Tedy mu akorát řeknu, co má spustit. A nemusím se zabývat hloupostmi, jako jak a kam si poznamenat PID procesu, jak zjistit, jestli proces stále běží, jak ho ukončit…

Systemd nepřevezme konkrétní ovládání, jenom umožní komunikaci mezi ovladačem a službou.

Jak? To by ta služba musela implementovat nějaké komunikační rozhraní systemd a stala by se tak na něm závislá. To snad nikdo soudný nemůže chtít (bez ohledu na oblíbenost toho kterého systému, byl bych proti i u nejlepšího init systému na světě - bez ohledu na to, že nic takového ani existovat nemůže, protože na každou situaci se hodí něco jiného).

Třeba univerzální konzolí, která bude umět ovládat různé služby (a nebude to dělat nebezpečným voláním konzolových nástrojů na pozadí doprovázeným modlitbami, aby nedošlo k chybnému souběhu).

To univerzální rozhraní už mám dneska. Říká se tomu shell. V této konzoli můžu ovládat veškeré prvky OS. (Závorku jsem četl, jestli se nějaký admin u práce s OS musí modlit, tak by měl pravděpodobně změnit zaměstnání.)

Tedy mu akorát řeknu, co má spustit. A nemusím se zabývat hloupostmi, jako jak a kam si poznamenat PID procesu, jak zjistit, jestli proces stále běží, jak ho ukončit…

To nemusíte ani u rc skriptu, protože to už v tom template vyřešené je.

To univerzální rozhraní už mám dneska. Říká se tomu shell.
Pod pojmem univerzální rozhraní si představuju něco, k čemu můžu připojit, co mne napadne – shell, GUI konzoli, webové rozhraní nebo třeba vzdálený management.

Závorku jsem četl, jestli se nějaký admin u práce s OS musí modlit, tak by měl pravděpodobně změnit zaměstnání.
Jak tedy v shellu řešíte to, že zjistíte stav, po té dáte pokyn ke změně – jenže mezi tím se stav mohl změnit?

To nemusíte ani u rc skriptu, protože to už v tom template vyřešené je.
K čemu je tedy celý ten rc skript dobrý, když je to jenom neustále se opakující šablona, ve které se jen změní dva řádky kódu? Není lepší ten opakující se kód někam vytknout a v konfiguraci služby nechat jenom ty dva řádky? Přičemž pořád nevím, proč jsou dva, normální procesy se ukončují zasláním signálu.

Jak tedy v shellu řešíte to, že zjistíte stav, po té dáte pokyn ke změně – jenže mezi tím se stav mohl změnit?

Jak se mohl změnit? Sám od sebe se nezmění. Služba, která běží, mohla náhodou spadnout, ale já nepoužívám služby, které jen tak padají (uptime 3 roky u mě znamená, že démoni, kteří nastartovaly při bootu běží 3 roky, nic menšího neakceptuji). I kdyby se vypnula, tak co? Pokud dám příkaz start, tak se znova zapne. Pokud dám stop, tak se neprovede nic. Pokud dám restart po změně konfigurace, tak se znova nahodí. V praxi navíc stav služeb nezjišťuji, takže se nedostanu do situace, že se mezitím změnil. Udělám rovnou tu akci, kterou chci. Ano, teoreticky lze vymyslet hromadu race, které jsou ale jen teoretické, protože v běžné praxi nenastanou, protože se ten systém používá určitým způsobem.

Není lepší ten opakující se kód někam vytknout a v konfiguraci služby nechat jenom ty dva řádky?

Ano, hromada rc systému přesně takhle vypadá. Ani nepoznáte, že píšete v bashi, protože vše společné je v základu.

Přičemž pořád nevím, proč jsou dva, normální procesy se ukončují zasláním signálu.

No tak si tam tu stop akci nedávejte a nechte jen volat sigterm. Jsou některé procesy, které (ačkoliv samozřejmě reagují na sigterm) tak mohou před samotným ukončením potřebovat ještě nějaké činnosti. Pokud je nepotřebují, ExecStop nechte prázdný.

Jak se mohl změnit? Sám od sebe se nezmění.
Sám od sebe se nezmění, ale může ho změnit nějaká událost nebo někdo jiný. Například zkontrolujete konfiguraci služby, je OK, tak necháte službu znovu konfiguraci načíst – jenže mezi tím došlo ke změně konfigurace. Třeba to způsobí nějaký automat jako utilita pro Let's Encrypt. Nebo nějaká úloha z cronu, třeba něco jako logrotate. Možná s tou konfigurací bude takový nástroj dokonce pracovat „bezpečně“, takže odstraní původní soubor a pak tam nahraje nový. A zrovna v tom okamžiku, kdy tam soubor nebude, se ho pokusí služba načíst. A možná dokonce bude chytrá, a když zjistí, že konfigurační soubor neexistuje, vytvoří nový defaultní. Pak se dostane ke slovu ta utilita, která tam chtěla nakopírovat tu změněnou konfiguraci, a spadne, protože nepředpokládala, že tam ten soubor bude.

Ano, je to nepravděpodobné. Ale rozhraní, které je postavené na tom, že špatně funguje jenom občas, není dobré.

Ano, teoreticky lze vymyslet hromadu race, které jsou ale jen teoretické, protože v běžné praxi nenastanou, protože se ten systém používá určitým způsobem.
Tenhle způsob uvažování stojí za všemi problémy se souběhem akcí.

Jsou některé procesy, které (ačkoliv samozřejmě reagují na sigterm) tak mohou před samotným ukončením potřebovat ještě nějaké činnosti.
Pak to mají dělat v reakci ne ten signál. Jinak opět může dojít k tomu, že necháte provést akce před ukončením, ale k samotnému ukončení pak už nedojde.

Sám od sebe se nezmění, ale může ho změnit nějaká událost nebo někdo jiný. Například zkontrolujete konfiguraci služby, je OK, tak necháte službu znovu konfiguraci načíst – jenže mezi tím došlo ke změně konfigurace. Třeba to způsobí nějaký automat jako utilita pro Let's Encrypt. Nebo nějaká úloha z cronu, třeba něco jako logrotate. Možná s tou konfigurací bude takový nástroj dokonce pracovat „bezpečně“, takže odstraní původní soubor a pak tam nahraje nový. A zrovna v tom okamžiku, kdy tam soubor nebude, se ho pokusí služba načíst. A možná dokonce bude chytrá, a když zjistí, že konfigurační soubor neexistuje, vytvoří nový defaultní. Pak se dostane ke slovu ta utilita, která tam chtěla nakopírovat tu změněnou konfiguraci, a spadne, protože nepředpokládala, že tam ten soubor bude.

Obávám se, že v systému, kde se budou služby chovat takto, tedy že si vytvoří default conf, že si odněkud vytáhnou starý conf pokud se jim ten nový nelíbí apod. těch races budete mít daleko víc a fakt by mě zajímalo, jak by třeba systemd řešil služby, které si, dle vašeho popisu, doslova dělají co chtějí. Takto se ty systémy neprovozují. Můžeme si vymyslet spoustu absurdních situací, kde to či ono nebude fungovat, ale v reálu se ty služby takto nechovají. Takový systém by se nedal používat.

Jak to tedy řešíte vy, aby služba nastartovala s vámi určenou a validovanou konfigurací, bez ohledu na to, co se děje okolo? Nebo to neřešíte a spoléháte na to, že jste jediný, kdo na tom systému reálně může provést nějaké změny, které službu ovlivní? Pokud je to ten druhý případ, jak dobře to vaše řešení škáluje?

A co třeba cron nebo sudo – takové služby nepoužíváte, když si nevystačí se shellem, ale mají proprietární nástroj pro konfiguraci?

cron má proprietární nástroj pro konfiguraci? Od kdy? crontab -e volá $EDITOR na kopii cron souboru z poolu. Klidně si vem jiný editor, změň soubor přímo v tom poolu a restartni crond.

sudo totéž v bledě modrém.

Pokud je to ten druhý případ, jak dobře to vaše řešení škáluje?

Škáluje co? Jako že 30 lidí bude současně nastavovat jednu službu? To teda moc dobře neškáluje, protože tam často ani není 30 věcí k nastavení ;-).

Jak to tedy řešíte vy, aby služba nastartovala s vámi určenou a validovanou konfigurací, bez ohledu na to, co se děje okolo?

No kupodivu tak, že po instalaci služby a jejím nastavení udělám service sluzba start a ona, světe div se, běží. Pokud ji chci spouštět při bootu, tak chkconfig sluzba on. Dokonce úplně stejně po instalaci na systémem se systemd po instalaci služby a jejích nastavení udělám systemctl start sluzba, systemctl enable sluzba (a takové věci jako hraní si s mask / unmask raději nebudu komentovat - viz diskuse o tom, jak v systemd skutečně zabránit tomu, aby se nějaký služba spustila).

crontab -e i sudo jsou proprietární nástroje pro konfiguraci. Když budete přímo editovat příslušný soubor, může to dopadnout dobře, ale také nemusí. Postup, který jste popsal, je popis konkrétní implementace těch proprietárních nástrojů. Takže vám nestačí znát standardní unixové nástroje, musíte znát ještě postup pro tu kterou konkrétní aplikaci.

Problém se souběhem může nastavit i v případě dvou konkurenčních přístupů, nemusí jich být dvacet.

Tvrdíte, že pořádná služba nepadá z ničeho nic a tedy nepotřebujete automatický restart procesů. Ale při správě služeb vám vůbec nevadí, že spoléháte na to, že to snad dobře dopadne – a kdyby se náhodou projevil nějaký problém způsobený souběhem, nevadí, prostě to zkusíte ještě jednou. Neměla by správa služeb být stejně spolehlivá, jako to vyžadujete od služeb?

jsou proprietární nástroje pro konfiguraci

Co je na tom proprietálního? Oba nástroje jen zavolají editor (který dokonce ani nevláčejí sebou, prostě použijí ten který je uveden v proměnné prostředí, případně defaultní), předají mu soubor k editaci a po zavření editoru jen zkontrolují správnost a upozorní démona (v případě cronu). Nic proprietálního na tom nevidím, naopak je to krásná ukázka použití již existujícího. Ale dokonce ani tyto nástroje nemusíte použít. Můžete klidně editovat sudoers nebo crony ručně.

Tvrdíte, že pořádná služba nepadá z ničeho nic a tedy nepotřebujete automatický restart procesů.

Ano.

Ale při správě služeb vám vůbec nevadí, že spoléháte na to, že to snad dobře dopadne – a kdyby se náhodou projevil nějaký problém způsobený souběhem, nevadí, prostě to zkusíte ještě jednou.

Já jsem někde tvrdil, že to snad dobře dopadne a náhodou a že to zkusím ještě jednou? Prosím o citaci. Ne, já svůj systém znám. To, že se konfigurace a restart služby podaří, není náhoda. Možná pro někoho jo, ale takového člověka bych neoznačil slovem administrátor.

Proprietární je ten správný postup. Ručně to editovat můžu, ale není zaručeno, že to bude fungovat. Není to krásná ukázka použití existujícího, je to ukázka hacku, jak s omezenými nástroji docílit bezpečné změny konfigurace.

Kdyby to nebyly proprietární nástroje, nepotřebujete crontab -e a visudo, když oba dva dělají to samé.

Já jsem někde tvrdil, že to snad dobře dopadne a náhodou a že to zkusím ještě jednou?
Tvrdil jste, že souběhy teoreticky nastat mohou, ale vy je neřešíte, protože to používáte určitým způsobem.

Ne, já svůj systém znám. To, že se konfigurace a restart služby podaří, není náhoda.
OK, máte svůj malý systém, ve kterém znáte všechny vazby, konkurenční přístup řešíte tak, že si pohlídáte, abyste žádné konflikty nezpůsobil. Já mám raději, když problém konkurenčního přístupu vůbec nemůže vzniknout. A v komplexních systémech je to nutnost, protože tam nikdo nemůže znát celý systém a posoudit, jestli někde náhodou nevzniknou nechtěné interakce.

Tvrdil jste, že souběhy teoreticky nastat mohou, ale vy je neřešíte, protože to používáte určitým způsobem.

Což ale vůbec neimplikuje to, že se to náhodou podaří a když ne, tak to zkusím ještě jednou. Pokud si z celého stavového prostoru vyberu jen ty stavy, ve kterých nastat konflikty nemohou a mezi těmito stavy se pohybuji, tak se mě ty konfliktní stavy netýkají.

OK, máte svůj malý systém, ve kterém znáte všechny vazby, konkurenční přístup řešíte tak, že si pohlídáte, abyste žádné konflikty nezpůsobil. Já mám raději, když problém konkurenčního přístupu vůbec nemůže vzniknout. A v komplexních systémech je to nutnost, protože tam nikdo nemůže znát celý systém a posoudit, jestli někde náhodou nevzniknou nechtěné interakce.

Samozřejmě. Malý systém. Když dojdou argumenty ... Mě by spíš zajímalo, jak se v produkční praxi stane, že nějakou službu budou konfigurovat dva a více adminů současně. Služba se typicky jednou nainstaluje a potom běží až do odstavení systému. Pokud nějaká služba potřebuje změnu konfigurace (což se mimochodem dá dosáhnout i tak, že se vedle nainstaluje služba s novou konfigurací a jen se zmigrují data), tak se pověří jeden konkrétní admin a ten rekonfiguraci provede. K žádnému souběhu nedojde.

Jestli je je vaší praxi běžné, že různí admini nastavují jen tak z plezíru různé služby do různých stavů a restartují je kolegům pod rukama, tak tomu se běžně říká sabotáž a s takovým "adminem" vyrazím první dveře a poženu ho třeba až na úřad práce (což teda v mém případě je jen do vedlejší budovy).

A hlavně nevím, jak by jakýkoliv systém na světě mohl zabránit tomu, že nějaký admin nastaví službu do stavu A a druhý admin tutéž službu paralelně do stavu B. Výsledkem stejně bude nakonec buď A nebo B. Možná se to náhodně 50:50 trefí do zamýšleného stavu, ale za dobrý výsledek to nepovažuju.

Prostě ten souběh se musí řešit na úplně jiné vrstvě.

Pokud si z celého stavového prostoru vyberu jen ty stavy, ve kterých nastat konflikty nemohou a mezi těmito stavy se pohybuji, tak se mě ty konfliktní stavy netýkají.
Nejde tenhle princip rozšířit na celý software? Prostě si nadefinujete, že ho používáte jenom způsobem, ve kterých funguje správně, a chyby se vás tím pádem netýkají. Akorát nevím, jestli bude software to vaše rozhodnutí respektovat.

Mě by spíš zajímalo, jak se v produkční praxi stane, že nějakou službu budou konfigurovat dva a více adminů současně.
Jak? No třeba administrátor databáze potřebuje přidat úlohu do cronu, a administrátor poštovního souboru potřebuje přidat svou úlohu do cronu. A ejhle, oba konfigurují stejnou službu.

A hlavně nevím, jak by jakýkoliv systém na světě mohl zabránit tomu, že nějaký admin nastaví službu do stavu A a druhý admin tutéž službu paralelně do stavu B. Výsledkem stejně bude nakonec buď A nebo B. Možná se to náhodně 50:50 trefí do zamýšleného stavu, ale za dobrý výsledek to nepovažuju.
Buďte rád, že stejný názor nemají třeba autoři bankovních aplikací. Že by prohlásili, že když vám mají přijít na účet dvě platby, přičte se vám buď jedna, nebo druhá, a neexistuje způsob, jak takovému konfliktu zabránit. Naštěstí ty způsoby existují, dva nejjednodušší jsou zamykání (před začátkem změny získám výhradní přístup, provedu změnu, a zámek vrátím), nebo verzování – načtu údaje s verzí, provedu změny, uložím verzi se zvýšenou verzí, pokud aktuální verze je nižší než nově ukládaná verze.

A ejhle, oba konfigurují stejnou službu.

Ano, ale za dva různé uživatele, takže každy z nich si zavolá crontab -e nebo každý z nich bude editovat svůj vlastní soubor. Potom ale nebude mít typicky právo zrestartovat tu službu, takže pokud nebude mít inotify (což momentálně nevím, zda crond nad poolem má), tak se jeho změny neprojeví.

Buďte rád, že stejný názor nemají třeba autoři bankovních aplikací.

Předpokládám, že ze sebe vzájemně nemusíme dělat blbce. Pokud ano, tak polopatě: stavy A a B jsou vzájemně protichůdné a nedají se sloučit. Zatímco bankovní transakce jsou samostatné. Pokud dva různí admini budou nastavovat jeden systém, tak ten s 50% pravděpodobností skončí nastavený špatně.

Proto říkám, že tento problém je nutno řešit na jiné vrstvě a nezadávat adminům protichůdné požadavky na jednu službu.

A co když ty dva požadavky A a B nejsou protichůdné a dají se sloučit? Třeba ta výše uvedená konfigurace cronu, pokud obě dvě úlohy mají běžet pod rootem (což je u správcovských úloh docela běžné).

Proto říkám, že tento problém je nutno řešit na jiné vrstvě a nezadávat adminům protichůdné požadavky na jednu službu.
Otázka je, zda si ten zadavatel v danou chvíli uvědomí, že administrátor databáze i administrátor poštovního serveru asi budou požadavky řešit pomocí cronu. Dokonce ani zadavatel těch úkolů nemusí být jedna a táž osoba.

Otázka je, zda si ten zadavatel v danou chvíli uvědomí, že administrátor databáze i administrátor poštovního serveru asi budou požadavky řešit pomocí cronu. Dokonce ani zadavatel těch úkolů nemusí být jedna a táž osoba.

Tomu se potom říká, že levá ruka neví co dělá pravá. Opět to není asi to nejvhodnější prostředí pro provoz serverů.

Jinak k tomu prvnímu odstavci, k čemu směřuješ? Je to tak, že služba, která nemá rozhranní pro administraci, které by umožnovalo přidávat jednotlivé záznamy a hlídalo by si stav, tak stejně funguje tak, že se v nějakém editoru otevře soubor a po jeho zavření se zkontroluje a aplikuje. Pokud toto udělají dva různí admini ve stejný čas, tak vyhraje konfigurace toho, kdo ten soubor uloží jako druhý. No a ten první admin si toho buď všimne, nebo ne. Každopádně služba nebude v očekávaném stavu.

Nejsem si jistý, jestli by pomohlo, aby každá služba měla vlastní nastavátko, které transkakčně vyřeší konfiguraci paralelními adminy. Evidentně to v praxi není takový problém, aby se to muselo řešit. A pokud to někdo potřebuje řešit, třeba přidávat položky do konfigurace tak často, že hrozí souběh, tak na to jsou už roky hotová řešení, nepřistupuje se ke konfiguračnímu souboru přímo, ale konfigurace se provádí prostřednictvím jiné služby, která řeší mimo jiné i souběh. Kdo chce použít, může, kdo nechce, nemusí.

Jde o to, že to dokonalé konfigurační rozhraní „textový soubor editovatelný libovolným editorem“ má také svoje mouchy. A ta výhoda, že existuje spousta unixových nástrojů pro práci s textovými soubory, je také víceméně teoretická, protože málokdy použijete něco jiného, než textový editor. Nemluvě o tom, že rozhraní „textový soubor“ ani nedokáže službu informovat o změně, to je potřeba provést jiným způsobem – dotazováním, restartem služby, signálem, inotify…

Takže tu sice máme univerzální konfigurační rozhraní postavené na textových souborech, ale to není dokonalé, takže je logické hledat lepší řešení. Nemusí to být zrovna systemd, a i kdyby bylo, přijde po něm zase něco dalšího.

Mate pravdu. Kurva, uz aby konecne do Linuxu integrovali registry a regedit (vyhradne s grafickym rozhranim). Co dela ten flakac Poettering?

Az budou registry, nikdo se nebude v nicem hrabat a admina bude moci delat kazdy debil.

Jde o to, že to dokonalé konfigurační rozhraní „textový soubor editovatelný libovolným editorem“ má také svoje mouchy.

Tak jistě že má.

A ta výhoda, že existuje spousta unixových nástrojů pro práci s textovými soubory, je také víceméně teoretická, protože málokdy použijete něco jiného, než textový editor.

No na konfiguraci, kde chci něco upravit, použiji typicky textový editor (krom takových onlinerů jako echo "neco" >> soubor.conf, které osobně nemám příliš rád). Ale ty ostatní textové nástroje jako grep apod používám jinak denně a častěji, než editor samotný (ale zase ne příliš často na konfiguráky).

ale to není dokonalé

Nic není dokonalé. Ani to lepší řešení nad konfiguráky by také nebylo dokonalé. Dokonce by přineslo své vlastní problémy, které před tím neexistovaly. Jak říká Murphy, vše se pokazí a pokazí se to v nejnevhodnější situaci.

Nevybavuji si jediné jednotné řešení konfigurace, které by někdy neselhalo (naposledy jsem se pokoušel konfigurovat NetworkManager čistě dle návodu a výhradně pomocí nástrojů k tomu určených - nevím proč, ale po třetí přidané statické routě to přestalo fungovat - takový nástroj je naprosto k ničemu). A potom je ten průser mnohem větší, než když se nějaký admin překlepne v jednom konfiguráku. Totéž je s tím systemd. Když se v initrc pokazí jeden skript, tak se v podstatě nic neděje a navíc každý admin má schopnost jej opravit nebo alespoň obejít. Když se pokazí něco v systemd, tak je admin většinou v prd...

Nic není dokonalé.
Jako náhrada za nedokonalé řešení není potřeba dokonalé, stačí pouze lepší.

Když se pokazí něco v systemd, tak je admin většinou v prd...
Myslíte přímo v programu systemd, tedy v PID 1? Kdy jste se setkal s tím, že se tam něco pokazilo?

Ne, myslím v balíku systemd jako celek. Tak třeba se pravidelné kazí journald logy. LP sice tvrdí, že dělají maximum proto, aby to přečetlo i vadné logy a ale pravidelně se stává, že se rozbije (mimo jiné) index bootů a nelze se vrátit zpět před vadný log. (Jako ono to nějak obejít jde, lze si vypsat seznam uid všech bootů nalezených v logu a potom si zobrazit každý jednotlivý log, ale to asi není zamýšlené použití nástroje journalctl.)

Když si spustím journalctl --verify, tak jsem zatím nenašel stroj, kde by nějaký log nebyl failed. Jsou to všechno zdravé stroje, které běží roky spolehlivě, fs je v pořádku atd. Prostě si to samo ničí vlastní soubory.

Nebýt možnosti forward to syslog, tak je admin bez logů.

Tím se ale systemd neliší od řešení bez systemd – tam jsou v jednotlivých komponentách také chyby.

Ty chyby s journald jsou nahlášené, má ty samé problémy také někdo jiný?

Ty chyby s journald jsou nahlášené, má ty samé problémy také někdo jiný?

To si děláš srandu, nebo máš klapky na očích? Jistě že jsou nahlášené a hlásí se už roky. Některé bugy journald skončily označené jako notabug (z toho lze vyvodit, že vadné logy jsou vlastnost), některé smazané apod, k některým napsal povídání i LP apod.

Mne nezajímají hlášené nějaké chyby. Vy jste psal o své vlastní zkušenosti, tak by mne zajímalo, jestli ty vaše konkrétní chyby jsou nahlášené.

Některé bugy journald skončily označené jako notabug (z toho lze vyvodit, že vadné logy jsou vlastnost),
Ne, to z toho vyvodit nelze.

některé smazané apod, k některým napsal povídání i LP apod.
Nic z toho ale nevypovídá o reálných chybách journald.

Pokud k tomu chcete přistupovat způsobem, že všechno, co je nahlášené jako chyba journald, je automaticky chyba journald, protože systemd, nemáme se o čem bavit. I v této diskusi je vidět, že někteří lidé prostě hodně nemají rádi systemd a svedou na něj cokoliv, s největší radostí pak na systemd svedou to, že mají obě ruce levé. Nemyslím si, že by se tihle lidé bugzille vyhýbali. Proto se ptám konkrétně na ty vaše chyby, protože u těch se asi můžu spolehnout na to, že je to opravdu vlastní zkušenost a ne „někde na internetu jsem četl“, a na to, že popis chyby bude plus mínus odpovídat realitě a popisovat skutečný problém. Kdybych si chtěl číst pohádky o tom, jak je všechno špatně, protože všichni jsou debilové, přečetl bych si nějaký komentář od j.

Nic z toho ale nevypovídá o reálných chybách journald.

Prosím? Takže bugy na vadné logy journald nejsou o chybách journald? Takových hlášení jsou v bugzilách desítky. Nebudu tu chybu hlásit ještě jednou sám za sebe (snad stačí nahlásit chybu jednou, není potřeba hlásit tutéž chybu (chybu stejné třídy) v každé jednotlivé instanci), jen proto, aby to skončilo jako duplicate nějakého jiného bugreportu označeného jako notwantfix, notabug apod.

To za prvné. Za druhé, a tady opět očekávám nějakou jízlivou reakci. Proč bych měl psát bug na něco, co se projevuje ve 100% případů? To autoři nebo testeři neodhalili? Nebudu ani psát bugreport na ten NetworkManager. Pokud nikdo z autorů nevyzkoušel přidat více statických rout, tak už jen toto je pro mě signálem ten soft prostě nepoužívat, protože při takovém způsobu vývoje a (ne)testování bych pravděpodobně hned po té narazil na další "vlastnost", kterou se autor neobtěžoval vyzkoušet. Toto je pro mě při výběru softu mimořádně důležité. Naopak si vážím projektů, které na férovku zruší z plánovaného release ohlášenou vlastnost, protože sami nejsou spokojeni s tím, jak ten kód vypadá. Ten projekt je dlouhodobě stabilní a je to právě důsledkem tohoto způsobu myšlení autorů.

v této diskusi je vidět, že někteří lidé prostě hodně nemají rádi systemd

Už jsem tu někde psal, že zrovna journalctl považuji za to lepší ze systemd a dokonce jsem oponoval lidem, kteří se obávali toho binárního formátu. V různých db mám hromadu TB dat a není nejmenší důvod, aby se ta data kazila jen proto, že jsou ve formátu té konrétní db. Proč se kazí logy journald neví, nevyčuměl jsem to z ničeho, vše ostatní v pohodě běží. Byl bych rád, kdyby nástroj jako journald fungoval správně.

Takže bugy na vadné logy journald nejsou o chybách journald?
Ne, hlášení chyby o vadném logu journald nemusí znamenat chybu v journald. Už jsem viděl asi tak milion hlášení, kdy někdo hlásí chybu v nějakém programu, a chyba je přitom v jiném programu, mezi židlí a klávesnicí, nebo o chybu vůbec nejde.

Nebudu tu chybu hlásit ještě jednou sám za sebe
Tak se pak nedivte, že ta „chyba“ není opravená.

bugreportu označeného jako notwantfix, notabug
K takovému označení mohou vést různé důvody. Vývojář si nemyslí, že jde o chybu, a oznamovatel ho o tom nedokáže přesvědčit. Vývojář nedokáže chybu reprodukovat a oznamovatel už nijak nereaguje. A nebo také to, že vývojář je hlupák a zjevnou chybu zazdí. S tím posledním opravdu nic neuděláte, ty první dva případy může pomoci vyřešit někdo, u koho se také chyba projevuje, a kdo to dokáže popsat lépe nebo bude schopen spolupracovat na opravě té chyby.

Proč bych měl psát bug na něco, co se projevuje ve 100% případů?
Reakce bude jízlivá, protože tohle si nic jiného nezaslouží. Stačilo by uvědomit si, že nejste pupek světa, a že to, že se vám chyba projevuje ve 100 % případů, neznamená, že se projevuje všem. Klidně je možné, že jste jediný, komu se projevuje.

Ten projekt je dlouhodobě stabilní a je to právě důsledkem tohoto způsobu myšlení autorů.
Jako příklady uvádíte systemd a NetworkManager. Oba jsou to komplexní systémy, které vstupují do oblasti, kde panuje pěkný nepořádek, a snaží se ten nepořádek nějak uklidit a postupně proměnit v nové čisté řešení. Nebo-li se musí poprat se spoustou podivuhodných hacků a zároveň se snažit nespadnou do stejné pasti. To není věc, kterou je možné obecně testovat, protože vždy přijde někdo s nějakou novou kombinací hacků, kterou nikdo neotestoval. To nemůžete srovnávat s „jednoduchými“ aplikacemi typu databáze nebo souborový systém (přičemž zde „jednoduchý“ a „komplexní“ nijak nesouvisí s tím, jaké jsou nároky na autory – je to prostě jiný typ problému).

Proč se kazí logy journald neví, nevyčuměl jsem to z ničeho, vše ostatní v pohodě běží. Byl bych rád, kdyby nástroj jako journald fungoval správně.
To by nepochybně byli rádi i autoři journald. To, že nedokážete zjistit, v čem je problém, je pochopitelné a nevytýkám vám to. Ovšem je trochu zvláštní to samé pak vytýkat jiným (autorům journald), ale dá se to pochopit, oni jsou „majitelé“ journald, ne vy. Ale když tu chybu nenahlásíte, nemůžete se divit, že ji nikdo neopraví. To, že se ta chyba projevuje vám, opravdu neznamená, že se musí projevovat i někde jinde. Proto je důležité, aby chybu nahlásil někdo, kdo je ochoten spolupracovat na jejím odstranění – v první řadě je potřeba v spolupráci s autorem přijít na to, co je ve vašem prostředí specifické. Když už se podaří dojít do stavu, kdy vývojář dokáže chybu reprodukovat, bývá oprava většinou triviální.

Ne, hlášení chyby o vadném logu journald nemusí znamenat chybu v journald.

Samozřejmě, že nemusí. Ale pokud jsou nahlášeny s tím, že všechno kolem je zdravé a jediný problém je s logy journald, tak ano, stále to nemusí být problém journald, ale je to nejlogičtější začátek hledání příčiny. Jenže z té bugzilly není často cítit ani žádná snaha to začít řešit.

Stačilo by uvědomit si, že nejste pupek světa

Uvědomuju. Proto taky takový software nepoužívám. Pokud mám tu možnost. Problém se systemd patrně časem vyřeším tak, že postupně přejdu na FreeBSD. Potenciální bariera je mnohem menší, než jsem čekal (prakticky nulová), některé služby (u kterých to bylo výhodné) už jsem tam popřehazoval a takovou pohodu s prací s OS jsem dlouho nezažil. Pokud se časem někdo zblázní i ve FreeBSD, stále bude mnoho projektů, kam dál.

To není věc, kterou je možné obecně testovat, protože vždy přijde někdo s nějakou novou kombinací hacků, kterou nikdo neotestoval.

Nevyčítám NetworkManageru, že nepracuje správně na nějakém hraničním routeru s milionem portů v nějakém složitém stavu. Vzal jsem čistou minimální instalaci enterprise distra, vzal jsem do ruky manual a jel jsem podle manualu. První věc, kterou u síťového stroje chcete udělat je nastavit síť. Nepovedlo se. Na kompletně čisté instalaci, která je ve stavu, který je plně v režii autorů distribuce. Možná je chyba v dokumentaci, nevím, je mi to jedno. Network Manager používat nemusím a nebudu. Se systemd je to poněkud horší.

To by nepochybně byli rádi i autoři journald.

Z těch bugreportů bohužel nic takového cítit není.

Tohle opět krásně vystihl Michal Kubeček (který, tuším, přímo pracuje v jedné enterprise distribuci):
https://www.abclinuxu.cz/zpravicky/systemd-230-a-systemd.conf-2016/diskuse#53

Problém se systemd patrně časem vyřeším tak, že postupně přejdu na FreeBSD.

Jo, to muzete. Potiz ale je, ze spousta softu v BSD pochazi z Linuxu a v Linuxu se mnozi soft, ktery je na systemd zavisly. Portace pak znamena, ze ta zavislost z toho musi byt nejak vykuchana, coz muze byt stale slozitejsi.

A pro spoustu uzivatelu prechod na BSD neni zrovna jednoduchy. Maloktere BSD distro ma instalator tak snadny, jako ma dnes Linux. A pokud ho ma, tak vyvojari bohuzel obvykle prestali podporovat 32 bity, kterych okolo lezi porad jeste hodne.

Potiz ale je, ze spousta softu v BSD pochazi z Linuxu a v Linuxu se mnozi soft, ktery je na systemd zavisly.

Toho jsem si vědom, ale nevím, jak danou situaci řešit. A nejsem sám. Víceméně doufám, že dlouhodobě rozumné projekty, které používám, budou rozumné i v budoucnu. Zaručené to nemám, jako nic na světě.

Ne, hlášení chyby o vadném logu journald nemusí znamenat chybu v journald.

Ono je uplne jedno, ci je to chyba. Dulezite je, ze poskozeni zurnalu nejspise zpusobi jeho necitelnost a takovyhle system by se hlavne nemel spolehat na to, ze bude vzdy slunecne pocasi a vysoky rosny bod. Cilem by mela byt alespon jakasi citelnost logu i v pripade, ze dojde k problemu. A to zajisti textovy format mnohem spolehliveji, nez jakysi podivny format binarni. Textovy format pak zajisti i to, ze ty logy muzu zkusit ciste kdecim a nejen pomoci nejakeho bazmeku, ktery dodavaji se systemd.

Tohle vůbec nezávisí na tom, zda jde o textový nebo binární formát. I textový i binární formát může být udělaný tak, že se bude z chyby velmi špatně zotavovat, ale i tak, že chybu správně detekuje a co nejdřív se z ní zotaví. Naopak u čistě textového formátu (ne žádné XML apod.) se snadno může stát, že chybu vůbec nepoznáte.

journalctl umí logy textově zobrazit i exportovat, takže to „kde co“ můžete použít na ten vyexportovaný soubor.

Ano, journald by měl zajistit, že i v různých podivných situacích budou logy dostupné. Jenže tady je to plné komentářů, jak s tím všichni mají špatné osobní zkušenosti, jak je na to spousta bugreportů, ale odkaz na bugreport nikde, detailnější popis chyby nikde. Mně je to podezřelé. Já když se potýkám s takovouhle protivnou chybou, znám odkaz na bugreport, a/nebo popíšu detaily, v jaké to nastává situaci, jak se to projevuje… Kdybych chybu popsal způsobem „nic nefunguje, nikomu to nefunguje, nikoho to nezajímá a je zbytečné to hlásit“, připadal bych si, že mi vůbec nejde o řešení té chyby, a že jsem si prostě jenom přišel zanadávat.

https://www.google.cz/search?q=journald+corruption - cca 115 milionů výsledků... to bude nějaká blbost u pár uživatelů, ne? Momentálně mám po ruce jediný stroj se systemd a světe div se, journalctl --verify tvrdí, že má nějaké soubory poškozené. Se strojem jinak žádné problémy nejsou, v podstatě na něm nic neběží, jen se na něm testoval upgrade na SLES 12.1. Jinak szstemd má momentálně otevřených 312 issues, nejstarší starý skoro rok, nikomu se to nechce řešit... Tomu říkám kousek softwaru ;)

Tady uz je jen jedine mozne reseni. Konecne vymyslet stroj casu a zapichnout Poetteringa Widlemi jeste v kolebce.

I textový i binární formát může být udělaný tak, že se bude z chyby velmi špatně zotavovat, ale i tak, že chybu správně detekuje a co nejdřív se z ní zotaví.

Aha. Tak tady bych uvital priklad txtoveho formatu, ktery se z vhyby spatne zotavi tak, ze uz nepujde precist a opravit ani hexaeditorem.

Export logu journactl jsou mi na dve veci, kdyz jsou poskozene a nejdou exportovat.

<root>
  <item>1</item>
  <item>2</item>
  <item>3</item>
  -->
</root>

Číst a vylepšovat to hexaeditorem samozřejmě můžete, ale pochybuju, že dokážete říct, kolik tam před poškozením bylo platných položek – zda žádná, jedna, dvě nebo tři.

Jo, ale tohle se mi leda tak rozhodi, neco mozna neprezije, ale v podstate z toho muzu porad neco vycist. Co vyctu z binarniho blobu? Nehlede na to, ze textak, jako mate v tom vasem pripkladu, se na logy v Linuxu asi moc nepouziva. Mozna, ze to tak nejaka apklikace dela, ale typicke to neni.

Z binárního formátu přečtete úplně to samé, jako přečtete z textového. Akorát tomu binárnímu formátu musíte rozumět, stejně jako rozumíte tomu textovému. Kdyby ten textový soubor nebyl v ASCII ale nějaké obskurní znakové sadě (třeba ROT13(ASCII)), bude to pro vás také binární blob.

Z binárního formátu přečtete úplně to samé, jako přečtete z textového. Akorát tomu binárnímu formátu musíte rozumět, stejně jako rozumíte tomu textovému.

Aha. Akorat, ze binarnimu formatu nikdo nerozumi tak jako textovemu. Takze kdyz mam textovy format, tak to v necem otevru a ctu. Kdyz mam format binarni, tak stravim pul dne hledanim dokumentace a jejim studiem a dalsiho pul dne pokusy o desifrovani poskozeneho logu dle nastudovaneho materialu. Pricemz si muzu byt jisty, ze to vse do priste zapomenu a budu moci zacit znovu, coz se mi u textaku tezko stane. A pokud v tech logach je zapnuta komprese, tak to muzu rovnou zabalit, protoze zmena jedineho bitu ma dalekosahle dusledky, coz u textaku nemuze nastat.

Opravdy me presvedceni o vyhodach binarniho formatu sili s kazdym vasim prispevkem.

Takže rozdíl není v tom formátu, ale ve vašich schopnostech. Na tom se shodneme.

Takže rozdíl není v tom formátu, ale ve vašich schopnostech. Na tom se shodneme.

Tak jiste, az ty logy budou obsahovat nahodna cisla, bude rozdil v tom,ze je diky nedostatku jasnozrivosti nedokazu interpretovat.

Navrhuji, aby skolni ucebnice nadale byly tisteny v binarnim formatu, aby pristi generace byly na systemd lepe pripraveny, nez ja, stara struktura, co se ucila cist akorat normalni text.

Jinak to nejde, sice můžeme použít překladače obrazu, ale v celým systému Matrixu je moc informací, časem si zvykneš, už to ani nevnímám, vidím jenom blondýnu, brunetu, zrzku… hele a co si dát panáka?

Tohle už se fakt nedá říct jinak, slušnost stranou, Jirsák, ty jsi normální kokot. Jestli věříš jen polovině toho co píšeš, tak patříš do ústavu. To je jako říct, že přečíst zašifrovanou zprávu bez klíče je jen o schopnostech a v podstatě by to měl každej umět, nebo je debil. Ale primární účel logu je, aby BYL ČITELNÝ! Raději uvidím v 1000 řádkovým logu 10 řádků nesmyslů, než abych kvůli těm 10ti rozdrbaným řádkům neviděl vůbec nic. Takže řeknu ti to znova. systemd je někde mezi alfou a betou, v produkci nemá co dělat, LP je arogantní fracek a jestli to takhle půjde dál, Linux půjde do prdele a každej, kdo potřebuje stabilní OS minimálně na servery, tak uteče k nějakýmu BSD. Mimochodem, instalace OpenBSD je sice v CLI, ale jinak je tak jednoduchá, že by to zvládla i moje malá dcera, kdyby jí někdo přečetl a přeložil co to píše a co to chce.

Neučí se rozdíl mezi kódováním a šifrováním v 1. semestru všech IT škol?

A do které kategorie se dá zařadit kódování bez rozumné dokumentace? Buď je to dementní kódování, nebo je to šifrování ve stylu "security through obscurity"? Substituční šifra je ve své podstatě taky jen kódování. Nic to nemění na tom, že když se něco pokazí, jsem prostě v tu chvíli v zadeli. Mimochodem, systemd po nějaké aktualizaci dokonce nedokázalo přečíst svoje vlastní logy z minulé verze. Tak to má vypadat? Ne, děkuji. Takhle by to opravdu nešlo. Prostě jsi pro mě kretén, kterej se zamotal do své vlastní blbosti a teď jsi se dostal do stavu, že za žádnou cenu nechceš vypadat jako debil, což si o tobě každej normální člověk myslí víc a víc s každým tvým dalším příspěvkem.

Když máš na logování vyčleněno 1kB zálohované RAM v embedded systému, jinou možnost, než binárka a přechroupávač na PC nemáš.

Tak vetsina lidi tady pri diskusi o logovani asi nema na mysli embeded systemy, ale vetsi stroje, tak od netbooku vyse. Pokud mate embeded system, tak si nejsem jisty, jestli zrovna systemd je ta idealni volba. Porad to bobtna a vtahuje to do sebe stale dalsi funkce, ktere predtim delalo neco jineho. Pokud chcete logovat binarne, asi by bylo lepsi si to resit nejakym vlastnim bazmekem, pokud takova vec uz nekde mimo systemd neexistuje.

Nezapomněl. systemd používám, vím co dokáže. ;-) Momentálně se snažím pochopit poslední changelog a to, co lennart boys vyvedli s odstřelením procesů po odhlášení uživatele a jaké je podle nich tedy správné řešení (tedy kromě toho nastavit si logind, protože se změnil default - bůh ví jak dlouho tam tam možnost bude). Prostě rozbili desítky let funkční nohup a screen / tmux. Přečetl jsem 5 man stránek a nechápu, jak se to má the systemd way nahradit. To, že taková nuance systemd-boys od nikdy nezajímala vím, ale někdy bych chtěl pro ukojení vlastní perverze zjistit, jaká je podle nich ta správná cesta.

Mno:

# apt install libpam-systemd
# loginctl enable-linger username

$ cat ~/.config/systemd/user/tmux.service:

[Unit]
Description=Start tmux in detached session

[Service]
Type=forking
ExecStart=/usr/bin/tmux new-session -s %u -d
ExecStop=/usr/bin/tmux kill-session -t %u

[Install]
WantedBy=default.target

a nastavit spouštění po loginu:

$ systemctl --user enable tmux

Funguje. Ať si každý sám za sebe rozhodne, jestli je to pro něj ok.

Jak to spustím interaktivně pouze když chci ne přímo po startu?

Systemd věci rozbíjí a nedává možnost náhrady svou cestou. Diktuje často jednu cestu, když admini jsou zvyklí na univezálnost a možnost udělat to jinak v případě potřeby. Unifikace vede k "Tesco kvalitě"

Tam je problém v tom, že tmux sice můžete spustit kdy chcete, jenže ve chvíli, kdy se z daného stroje kompletně odlásíte (všechny vaše session - což je typicky jen jedna session, právě ta, ve které chcete nechat spuštěný ten tmux / screen i po odhlášení ze ssh), tak systemd všechny vaše procesy zabije. Takže i ten tmux / screen. Dá se to vyřešit nějakým nastavením logind a použitím systemd-run. Nezkoušel jsem, nepátral jsem. Chci mít tmux nastartovaný trvale (v tomto případě tedy od prvního přihlášení).

Staci prepsat vsechen SW aby konzole komunikovala se serverem pres d-bus

Tohleto nevyslovujte ani ze srandy. Už dneska se najdou magoři, kteří tohle vzali vážně (naštěstí se lze jejich výtvorům vyhnout), čím méně jich bude, tím lépe.

V pripade toho Oracle to dnes funguje tak, ze spustite sqlplus a ten spusti process oracle jako syna. Tomu synovi preda nejake parametry pres environment, a pak s nim komunikuje pres presmerovany stdin/stdout. Pekne "unixove". Ta databaze bezi takovem single-user mode, kdy je mozne menit nektere parametry anebo spustit jeji restore. Pokud pak zadate urcity prikaz tak ze syn odforkuje a stane se samostatnym demonem.

+1, skvělé.

co by se stalo, kdyby ta šablona prostě byla program, který si ty parametry vycucne z jednoho nebo dvou řádků v konfiguráku a udělá to stejný?

Nestalo by se nic. Viděl jsem implementace, které fungovaly přesně takto. V rc skriptu byl jen nutný obal (v podstatě je source jiného skriptu) a ty dva řádky se tam napsali v podstatě jako argument nějaké funkce obalené nějakými dalšími drobnostmi (v podstatě definice fce, která se snaží tak nevypadat).

A problém je, že každý napsaný řádek zvyšuje riziko chyby. Ať je to skript, nebo kus programu. A i přiohnutý modul podle šablony se musí otestovat, takže unit testy nebo práce tesťáka navíc...

Start a stop akce tvého programu předpokládám testuješ vždy. V čem je rozdíl, když se ta start akce zavolá pomocí systemd a nebo pomocí skriptu v bashi?

Já jsem psal, že dotyčný programátor bude průměrný nebo podprůměrný v psaní shell skriptů – a vy jste k tomu doplnil, že bude také průměrný nebo podprůměrný v C, Qt/C++, Javě a PHP. Já dodávám, že pokud to dobře dopadne, bude nadprůměrný v tom, v čem píše ten svůj program – ani ne celý jazyk plus platformu, ale tu část platformy, kterou pro svůj program používá.

Mezi „být dobrý programátor“ a „umět jazyk“ je rozdíl třeba jako mezi „znát pravidla šachů“ a „být dobrý šachista“.

stejně to potřebuje při práci v konzoli
Já při práci v konzoli rozhodně bash znát nepotřebuju. A naopak neznám init systém, který by jako shell používal zsh.

Kvůli nějakým startovacím skriptům se nemusím učit sémantiku a syntaxi dalšího jazyka, který nikde jinde k ničemu nevyužiju.
Syntaxe je to nejmenší. Sémantiku se učit musí, protože init skripty nejsou jen tak nějaké skripty nezávislé na prostředí. Init skripty jsou komponenty daného init systému, obecně nepřenosné mezi init systémy – a pouze shodou okolností mají stejnou syntaxi, jako nějaký shell.

To mi pripomina PR kydy o zarne budoucnosti od byrokratu z EU.

Příklad: serverovna se sama přizpůsobí aktuálnímu výkonu, bez toho, že by nějací admini naskriptovali chování jednotlivých serverů.

Ano, soudruh Poettering pry jiz pracuje na implementaci interfejsu pro kristalovou kouli, ktera bude instalovana v kazde serverovne a zaruci, ze vykon bude nasazovan vzdy presne v souladu s pozadavky dane serverovny. Admini nebudou v serverovne vubec potreba, bude tam akorat technik, ktery z racku a hlavne z kristalove koule bude luxovat pavuciny.

No procesor už dnes přiděluje prostředky úlohám i bez admina, na základě adaptivního algoritmu, ...

Aha. Takze dneska je procesor jaksi chytrejsi, nez OS a umi se rozhodnout, kolik strojoveho casu da databazi, kolik webserveru nebo kolik Openoffice a kolik piskvorkam?

Budoucí kávovary budou vytvářet specifické chutě kávy (frakční destilací polosyntetické, nebo geneticky upravené kávy, ....

Jesteze kafe moc nepiju. A v dobe IoT se kafe tedy uz nedotknu ani klackem od hovna. A budu se muset zasobit zelenym cajem, nez ho nebezpecni silenci vaseho typu zkurvi take.

Earl grey jsou splasky zcela v duchu vasi geneticky modifikovane, frakcne destilovane kavy.

Ono se da prodat vsechno. Pigy caj, parky z odpadku.... Earl grey byl pokus, jak ucinit levny vaj pitelnym tim, ze se bergamotem zamaskuje chut neprilis kvalitniho caje. Casem si to naslo sve amatery. A lidi, kteri piji zeleny caj, casto nepiji caj cerny, protoze jim jaksi pripada podradny (a me po nem pali zaha). Earl grey sice obcas lze najit v zelene verzi, ale neni to zadna slava.

BTW, clovek nemusi byt prilis snobskym pijakem caje na to, aby nepil Earl grey. Ono je mozne najit slusne zelene caje, ktere nejsou moc drahe a vzhledem k tomu, ze v nich jeste neni systemd a na krabicce fotka Poetteringa, tak jsou docela dobre.

A az tam cokoli prestane fungovat, tak si admin rovnou hodi masli, protoze nebude mit zadnou sanci s tim cokoli udelat. Ja bych rek, ze Windows uz tu mame, tak proc delat dalsi?

Lebo ja sa iba začínam kamarátiť so systemd a ukazuje sa mi

1. Wants - keď spustím službu musia sa počas bootu spustiť aj wants
2. After - služba sa spustí, až keď bežia všetky After služby.

Teda ak by nebolo After tak by sa to fungovalo asi ako spúšťanie inštrukcií v poradí a ukončovanie mimo poradia. A to môže vadiť.

A navyše Wants hovorí, že ak sa niečo Z nich nepustí tak to oznám A pokračuj V štarte úlohy. Requires stanovuje, že sa musí služba vypnúť ak sa nepodarí niečo z Requires spustiť

Cílem je adminů se zbavit, stroj by se sám měl naučit, co kdy spouštět.

Aha, takze systemd se jednou stane umelou inteligenci. Uz se tesim, jak mam v notebooku 128 jader a 128 TB RAM na to, aby ta umela inteligence mela na cem bezet. BTW, co az ta umela inteligence usoudi, ze lidi jsou vlastne k nicemu a tak necha ten reaktor v elektrarne vyletet do luftu?

Jinak tedy ocekavam, ze objem kodu systemd brzy prekroci objem kodu jadra a vsech knihoven a aplikaci, ktere pro Linux existuji. Budouci distribuce Linuxu budou obsahovat systemd, jadro, par knihoven a textovy instalator. Vic se na tech 10 BlueRay disku nevejde.

Ano, už minule jsem Vám dokázal, že třeba logind bez systemd neběží a vytváří tím závislost závislost na systemd.
Takhle funguje princip „dělej jednu věc a dělej ji pořádně“. Když program potřebuje udělat něco, co není jeho doménou, použije k tomu jiný program, který právě tohle dělá.

Slovo další indikuje mnoho, nebo už začíná obvyklé podsouvání slov?
Nerozumím, na co se ptáte. Dnes existuje mnoho způsobů definic služeb, každý init systém používá vlastní, a často se to i u jednoho systému liší napříč distribucemi. Proto jsem se ptal, který z těch mnoha stávajících způsobů měl použít systemd.

Ovšem systemd neřeší jenom to co píšete, ale spolkl i spoustu jiných věcí a pohřbívá kompatibilitu.
To klidně může být pravda, ale nijak to nedokazuje vaše původní tvrzení, že ošetření závislostí služeb měla být nějaká „super cool feature“ systemd.

Ale systemd to nedělá. Nepoužije k tomu jiný program, zde by to byl samostatný logind, ale použije vnitřní část blobu. A co není v blobu, tak se tam přidá.
Tvrdil jste, že logind závisí na systemd. Což by bylo v souladu s unixovou filozofií – logind dělá pouze to, co je jeho účel, na správu služeb používá funkce systemd. Podobné řešení najdete u spousty dalších unixových programů – třeba qmail nebo Postfix, porovnejte si je se Sendmailem.

Vždyť to ošetření závislostí služeb je to hlavní, čím se systemd ohání že řeší.
Nikoli. Nic takového není napsané na webu systemd, v článku, na Wikipedii, na wiki Debianu, na wiki Archu… Netuším, kde jste to sebral.

„Systemd je správce služeb“ je úplně jiné tvrzení, než vaše „nejdůležitější funkcí systemd je řešení závislostí služeb“.

SysVinit je také správce služeb a závislosti neřeší.

Každopádně to byl hlavní argument, že řeší závislosti, ostatně se o tom píše i v článku hned v prvním dílu
Ano, je to váš hlavní argument. Jenom netuším, jak jste na něco takového přišel. V článku je to uvedené na začátku třetího odstavce vlastností systemd, navíc hlavně v souvislosti s řešením cyklů. Hlavní vlastnost by byla uvedená na začátku prvního odstavce, nemyslíte?

Vážený trolle, nepodsouvejte mi věci, které jsem nikdy netvrdil. To, že musíte postupně upravovat svá vlastní tvrzení, to je váš problém.

Začal jste tím, že řešení závislostí má být údajně vlastnost systemd, která je pro systemd klíčová a odlišuje jej od ostatních správců služeb. Teď najednou tvrdíte, že správa závislostí je hlavní úlohou každého správce služeb. To je pravý opak toho původního tvrzení. Popíráte sám sebe, a ještě to zkoušíte svést na mne.

Hlavním úkolem SysVinitu, OpenRC, daemontools i systemd je správa úloh. Některé z jmenovaných správců k tomu používají správu závislostí, některé ji nepoužívají – z čehož je patrné, že správa závislostí nemůže být jejich hlavním úkolem.

Takže podle vás „super cool feature“ znamená „nezajímavá vlastnost, kterou už má každý“. Dobře.

A napsal jsem, že o systemd se pořád tvrdí že to má konečně pořádně vyřešit služby a závislosti v jednom.
Ano, to jste si vymyslel a napsal, a vůbec se nenecháte rozházet tím, že vás opakovaně upozorňuju, že je to pouze vaše tvrzení a nikde jinde to napsáno není.

i v článku je to hned v prvním díle, hned první příklad užití.
Netuším, na co se odkazuje „první díl v článku“. Já jsem odkazoval na článek, pod kterým diskutujeme, a v něm to jako „super cool feature“ označené není.

Už minule jsem Vás prokoukl. Prostě si něco vyberete, lehce to ohnete a pak na to začnete odpovídat dalšíma otázkama na tu ohnutou věc.
Prokoukl jste dobře, ale sebe. To vy jste začal u „ošetřování závislostí a služeb je super cool feature“, skončil jste „správa procesů a jejich závislostí“, a tváříte se, že je to pořád to samé. Ano, na ty vámi ohnuté věci se ptám, protože se snažím zjistit, proč jste je ohnul.

Pokud v textu "super cool feature" čtete něco jako nezajímavá nebo je to v překladu „nezajímavá vlastnost, kterou už má každý“ nebo vlastnost kterou nikdo nemá, tak doporučuji očního lékaře a nebo psychologa.
Nikoli, já to čtu jako jako „vlastnost, která je pro systemd klíčová a odlišuje jej od ostatních správců služeb“. Ale to už jste napsal, že takový význam to nemá. Zajímalo by mne, co jste tím tedy chtěl říct.

automatické řešení závislostí
Aha, takže do sbírky synonym k „ošetřování závislostí služeb“, „správa úloh a jejich závislostí“ a „konečně pořádně vyřešit služby a závislosti v jednom“ můžeme přidat „automatické řešení závislostí“. Vy byste se asi nudil, kdybyste pro jednu věc používal jeden termín, že?

Tvrdil jste, že logind závisí na systemd. Což by bylo v souladu s unixovou filozofií – logind dělá pouze to, co je jeho účel, na správu služeb používá funkce systemd.

Problem neni v tom, ze logind zavisi na systemd, ale v tom, ze logind zavisi vyhradne na systemd. Take v tom, ze se systemd nemuzu pouzit loginbflmd. A kdybych mohl, otazka je, zdali by Gnome skousl fakt, ze misto logind ma k dispozici loginbflmd.

Jinak co nechapete na tom, ze je uchylne, kdyz kvuli Gnome musim mit logind, kvuli kteremu musim mit systemd? Proc tedy neintegrovat Gnome do systemd rovnou? Stejne uz tam je Tetris a ovladac dveri od garaze.

Znovu, muzete poslat zmeny, ktere kompatibilitu zlepsi.
Na jadro si ale taky nestezujete, ze dela IPC totalne jinak nez ostatni otevrene operacni systemy te doby. Viz diskuze edge vs level triggered a Bryan Cantrill (http://www.bsdnow.tv/episodes/2015_11_23-the_cantrill_strikes_back). Nakonec i systemd s sd-event kolem teto problematiky pracuje a v podstate dava za pravdu Bryanovi (http://0pointer.net/blog/introducing-sd-event.html).

Paralelizace neni spatna vec a i kdyz musi clovek vic premyslet, tak dlouhodobe urcite prinos viditelny je. Napr. pri nasazovani virtualnich stroju. Predstavte si, ze provozujete desetitisice virtualnich stroju jako kdejaky provider/ hoster dnes. To potom rozdil v rychlosti spusteni muze mit vyrazne financni dusledky a rozdil ve spokojenosti zakazniku.

1) Logind bude integrovan do systemd. Pri loginu bude zobrazovat fotografii sklebiciho se Poetteringa, coz system ochrani pred neautorizovanym pristupem, protoze se kazdy utocnik desne lekne.