Proč používat systemd

Lennart Poettering odpovídá svým zápiskem na otázku, proč používat systemd. Jedním z důvodů, které uvádí, je stadardizace linuxových distribucí. Systemd je v zápisku porovnáván s Upstartem a klasickým sysvinitem z hlediska funkcí, které nabízejí.

29.4.2011 16:24 | Nicky726 | Zajímavý článek

Komentáře

[stativ]

No, prakticky všechno co má v těch jeho tabulkách u systemd "yes", by podle mého názoru v initu vůbec být nemělo…

[vlastagf]

slusnej moloch

[michich]

Ale to, že je něco uvedeno v té tabulce, ještě nutně neznamená, že to má na starosti PID 1.

[Jesus Jimenez]

uff, nechtel bych to ladit...

[chrono]

Som zvedavý, ako dlho bude trvať, kým sa niekto objaví s niečím ešte lepším (je veľmi pravdepodobné, že to bude oveľa skôr, ako bude systemd prehlásený za stabilný).

[Radek Hladik]

Doprčic, to zas bude v alejích nablito

Ale vážně, ač se mi některé myšlenky líbí, tak opravdu doufám, že bude nějaký hezký a jendoduchý návod, jak naprostou většinu toho vypnout, nejlépe včetně celého systemd. Hlavně mi jde o servery, na desktopech to vzal čert. Ale server bootuje jednou za čas a moc se líbí, když mám jeden velkej init skript na začátek a pak spoustu malých pro jednotlivé služby. A hlavní výhody?:

* Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí

* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

* Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.

Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...

Příklad za všechny: Kdysi jsme měli ve firmě po různých zákaznících roztroušeno docela dost serverů. A přes veškeré snahy se ty servery občas restartovaly a pak se zarazily na potřebě fsck. Z různých důvodů jsme vybrali řešení, kde server, který by rád kontrolu disku, nahodí síť, spustí ssh a pošle maíl. Admin se přihlásí, opraví a voila.

Půjde toto udělat v systemd? Jak to bude složité? Jak moc se do toho bude člověk muset hackovat? V normálním sysinitu si člověk našel všechny výskyty fsck v jednom skriptu a v případě, že to selhalo, tak přidal jeden řádek s něcím jako /sbin/emergency. Pak už šlo jen o to, odladit ten skript tak, aby vše fungovalo s read-only rootem, atd... Pointa je v tom, že člověku stačilo ani ne 5 minut na vyřešení té části ohledně initu a nemusel být žádný systemd hacker. Samozřejmě, že moje řešení mělo problémy při update těch systémových skriptů, ale s diff+patch to byl detail.

[mirec]

Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí

Nepovedal by som. Mám gentoo, kedysi som začal používať openrc a následne som zapol aj paralelné spustenie. Aj na jednojadrovom stroji to začalo bootovať zhruba 2x rýchlejšie. Výhoda paralelného štartu je v tom, že zatiaľ čo sa systém hrabe na disku služby, ktoré už majú načítané dáta sa môžu pekne počas hrabania spúšťať.

Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

Mám gentoo a mám závislosti medzi službami. SSH mi ale rozhodne nespúšťa ani nezastavuje sieť. Závislosti sú hlavne medzi službami, ktoré potrbujú k svojmu behu iné služby. Väčšinou je to v celku príjemná pre užívateľa transparentná záležitosť, postačí do init skriptu napísať čo sa má pred ním spustiť a o všetko sa postará systém. Nemusím mať tak nastavených pri boote milion rôznych služieb, ale len tie, ktoré fakt potrebujem a zvyšok sa vďaka závislostiam natiahne samo.

Inak v systemd nie je taký problém používať pri spustení bash skripty ako teraz.

[Radek Hladik]

Chápu, že to paralelní spuštění něco ušetří, protože se prostě ty zdroje lépe rozloží mezi ty procesy, prostě se to tak nějak poskládá k vyšší efektivitě. Ale i na notebooku mi celý linux bootuje asi 15 vteřin, což považuju za krásný čas.

Co mi právě na tom vadí je, že se jedná o tak základní věc, že není pořádně možnost volby. Například moje oblíbená Fedora plánuje systemd už v F15. A určitě se nedá očekávat, že se budou udržovat dva nekompatibilní systémy startu. Nebo že se prostě jen stávající init nahradí systemd, ale celé skripty zůstanou stejně. Samozřejmě můžu přejít na jinou distribuci, ale to je navrabcekanonální řešení.

Obdobně s těmi závislostmi. Pokud budou mít jinou logiku, než čekám, tak se možná dočkám zajímavých efektů (to bylo jádro té mé připomínky se SSH). Radši bych žádné závislosti neměl, je pravda, že běžně mám v systému klidně 100 init skriptů, ale nikdy jsem neměl problém si je projet a naklikat co chci a co ne. A když udělám restart jedné služby, tak přesně vím, co se stane a co ne.

[pavlix]

Ono je potřeba se smířit s tím, co Fedora je. Ona je to sice komunitní distribuce, ale víceméně zaměřená na co nejrychlejší zařazení nových vlastností, což holt něco stojí. Někdy i tu možnost výběru.

Já si myslím, že systemd je schopný ušetřit daleko víc pomocí různých on demand služeb. Ale není to něco, co se naplno projeví hned ve Fedoře 15.

Bral bych to jako první krok k tomu mít možnost odlehčit start jak se dá. A tím nemyslím jak se dalo dosud s různými omezeními, ale jak se dá doopravdy.

Já právě závislosti oceňuju, protože to je přesně způsob, jakým chci pracovat. Mám určitou sadu služeb, které potřebuju k běhu (některé se pustí před přihlášením, jiné po přihlášení, jiné až po spuštění nějaké aplikace). Závislosti umožní zjistit všechny další služby, které jsou potřeba, aby se to nesesypalo.

Restart jedné služby „na vrchu“ podle mě má restartovat jednu službu, restart třeba sítě má podle mě restartovat minimálně všechny síťové služby, které se s tím restartem nedokážou smířit samy.

[mirec]

Ale i na notebooku mi celý linux bootuje asi 15 vteřin, což považuju za krásný čas.

Neverím. Pod 15s mi nenaštartuje ani len sieť a nie ešte hrúzy ako X.

[marvn]

hmm...sucks to be you :)

[j]

Pokud si pamatuju, tak pokud se pri tom paralelnim startu neco podela, tak je problem zjistit co se podelalo. Pri klasice se jednoznacne vi, ze to bylo to co startovalo posledni. Tudiz pokud se budeme bavit o desktopu, kde na tom moc nesejte, tak budiz, ale na server tohle proste nepatri.

[mirec]

A prečo by som to nevedel? Pri boote ak mám zapnuté výpisy tak pekne vidím kde nastal problém (akurát je ten boot rýchlejší, ale výpisy sú podľa mňa ešte o niečo prehľadnejšie). Ak nemám zapnuté výpisy vypíše sa chyba aj tak (automaticky sa prepne režim do verbose). Ak mám všetky výpisy potlačené tak tu mám logy (úplne rovnako ako u sériového štartu). Ak nemám logy tak som proste debil ale môžem si za to len a len sám.

[mirec]

Příloha:

• konzola.png (16807 bytů)

V prílohe je screenshot z výpisov pri boote. Prvá časť je sériový štart a potom nastupuje paralelný štart. Reálne tu u gentoo fakt nie je takmer žiaden rozdiel medzi paralelným a sériovým štartom (rovnaká reakcia na chyby, podobné výpisy ..). Paralelný štart mi zatiaľ zlyhal len pár krát pri ceste vlakom a aj to bol vinník hdaps, ktorý som mal príliš citlivo nastavený a kvôli našim skvelým tratiam mi odparkoval disk ;) Myslím, že v prípade, že nie je možné čítať z disku by sa viac-menej sekol každý init systém.

[Kaacz]

Takze setkani s realitou (osuse 12.1 se systemd po upgrade):

1) standardne systemd pri paralelnim spousteni na konzoli nepise NIC. Je to jako widlows, kdyz se to na necem sekne, nevidim nic a nevidim to ani na jine konzoli. Mohli to alespon flakat jinam, podobne jako na F10 jsou ty kernel vypisy. Ano, nasel jsem v konfiguraku neco o vypisech na konzoli, zkusim to enablovat. Coz ale v pripade nenabootovani uz nezmenim, jedine z live a opravit.

2) Ted se mi povedlo, po par upravach na serveru, ze restart uz neprosel. Ani do login v S mode. Ani volbou safemode v grubu. Jedine co pomohlo v grubu F5 a vybrat INITV misto Systemd .. skvele! ted Googlim, jak tento stav nastavit TRVALE. Potrebuju aby mi server bezel i po remote reboot a ne abych u nej stravil 2 dny ladenim a rebootovanim. Jedine co jsem nasel bylo nenastartovani Mysql, protoze jsem mu sebral nejaky soubor. Ale to bylo jen 30 vterin zdrzeni pod initv. Fakt nemam ted cas to znova rebootovat a zjistit, jestli to vadilo systemd.

[JoHnY2]

Podle me bude zalezet na distru, nekdo bude mit systemd jedna basen pro vsechny a nekde to bude na vidle a gumaky ... ono je to tak i s sysvinit a upstartem.

Mimochodem pokud to neni shoda jmen, tak diky moc za zalozeni libvirt-php.

[Radek Hladik]

A to je to, čeho se bojím. Nerad bych jen kvůli systemd odcházel od své oblíbené Fedory, kde mi všechno jinak vyhovuje. Proto právě doufám, že bude nějaký snadný postup (nejlépe jeden balíček přes yum install :) ), který všechny ty novinky vypne a bude se alespoň tvářit podobně, jako je to teď

Shoda jmen to není a díky za pochvalu.

[pavlix]

Ono se to ve výsledku bude používat podobně. Lidi jsou na to zvyklí a systém start-stop-restart fungoval vždy dobře. Takže i když vespod bude systemd, způsob práce se podle mého osobního názoru zásadně nezmění.

[Radek Hladik]

V to doufám, ale obávám se, že tento experiment má našlápnuto právě k tomu, to dělat "lépe a radostněji". Takže sice udělám start, ale ono to jen založí socket, při té příležitosti mi to spustí něco dalšího, atd... Úplně geniální by bylo, pokud to půjde přepnout do režimu: žádné novoty (typu sockety a spol) a žádné závislosti - jen mi napiš něco: "hele, spouštíš X, já bych doporučoval i Y, ale šahat ti do toho nebudu, zmasti si to sám "

[Heron]

Vidím to hodně podobně.

Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí

Má to i mít nějaký readahead, takže je klidně možné, že jedno vlákno bude přednačítat data spouštěných služeb, ty by potom skutečně mohli startovat paralelně a o něco rychleji. Ovšem nejsem si jist, jestli celá tahle námaha za to opravdu stojí, u serveru, který se rebootuje jednou za update.

Mám teď pokusně rozjetý Debian 6, kde je taky nějaké paralelní spouštění a už jen takový výpis spouštěných služeb při startu systému je dost zmatený (některé výpisy jsou přes sebe). Což se dá samozřejmě ošetřit, ale opět je to jen zbytečná práce navíc.

Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

IMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla). Při vypnutí ssh bych očekával, že se nic dalšího nevypne. I když i toto je diskutabilní. Ne vždy, když zapínám nějakou síťovou službu u toho chci zapínat ještě síť (ve smyslu nastavovat IP z nějaké konfigurace).

Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.

Na tohle jsem reagoval úplně stejně . Spousta služeb se startuje poměrně dlouho a startovat je až ve chvíli, kdy se tam připojí klienti ničemu nepomůže, naopak, ti první klienti budu čekat, až se to nastartuje. Kdyby ty služby již běželi, tak to mají hned.

[Radek Hladik]

Vidím to hodně podobně.

Paralelní spouštění - je to opravdu paralelní, když mám pořád jen jedno CPU a jeden disk? Je sice v módě mít víc jader, ale stejně většina služeb při startu hrabe na disk. A i kdyby, tak ta úspora za to jasně definované pořadí jedno po druhém prostě nestojí

Má to i mít nějaký readahead, takže je klidně možné, že jedno vlákno bude přednačítat data spouštěných služeb, ty by potom skutečně mohli startovat paralelně a o něco rychleji. Ovšem nejsem si jist, jestli celá tahle námaha za to opravdu stojí, u serveru, který se rebootuje jednou za update.

Mám teď pokusně rozjetý Debian 6, kde je taky nějaké paralelní spouštění a už jen takový výpis spouštěných služeb při startu systému je dost zmatený (některé výpisy jsou přes sebe). Což se dá samozřejmě ošetřit, ale opět je to jen zbytečná práce navíc.

To je právě ono. Já chápu, že na desktopu a spol to může být zajímavé. Konečně už Win NT4.0 vyskočily login dialog vcelku brzo, sice se nedalo přihlásit, protože neběžela služba winlogon, která se spouštěla podle abecedy,..... Ale když se ladí, proč se to při startu poto nebo proč něco nefunguje, tak díkybohu (jsouce ateista ) za jednoduchý spouštění one-by-one.

Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

IMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla). Při vypnutí ssh bych očekával, že se nic dalšího nevypne. I když i toto je diskutabilní. Ne vždy, když zapínám nějakou síťovou službu u toho chci zapínat ještě síť (ve smyslu nastavovat IP z nějaké konfigurace).

Já jsem právě narážel na to, že nějaký přechytralý systém závislostí dojde k pro mně nečekanému závěru, že když už neběží žádná služba, co by potřebovala síť, tak tu síť vypne. Na mém obstarožním iPAQu mi nefungovala OpenVPN jen proto, že ten jejich chytrý manažer síťových připojení odpojil GPRS ve chvíli, kdy zjistil, že v systému je (virtuální) síťovka...

Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.

Na tohle jsem reagoval úplně stejně . Spousta služeb se startuje poměrně dlouho a startovat je až ve chvíli, kdy se tam připojí klienti ničemu nepomůže, naopak, ti první klienti budu čekat, až se to nastartuje. Kdyby ty služby již běželi, tak to mají hned.

Tak a druhá věc, které se obávám, je maglajs při startu. To mi nejdřív vznikne spoustá "dutých" socketů, pak přijde nějaký požadavek na službu (nejlépe přímo při bootování), ty služby se tak nějak začnou startovat (paralelně), já budu doufat, že se nezacyklí a že časem se to dostane do stavu, kdy to všechno běží? A co když se služba nespustí? Teď normálně zahlásí Failed, já se kouknu do logu a hle vidím, chyba v konfiguraci... Ale takhle? Služba běží, vše je ok, v socketu jsou nějaká data, ale nějak se nedaří spustit toho, kdo se o ně má postarat.... Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítám Asi se stanu členem vývojového týmu a budu nenápadně škodit, ať se to nikdy nevydá ( a patentuju si guerilla developmnet)

[pavlix]

Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítám Asi se stanu členem vývojového týmu a budu nenápadně škodit, ať se to nikdy nevydá ( a patentuju si guerilla developmnet)

Takyže jsi konzerva :).

Myslím si, že logování nikdo nezatracuje, a failed služby budou úplně stejně failed jako dřív. Běžící aplikace zahlásí, že nedostala data ze sockety, o poruchové aplikaci init program zahlásí, že se ji nepodařilo spustit a ona sama pravděpodobně někde vypíše konkrétní důvod.

Píšu jen svůj pohled na to, jak by to mělo vypadat. Je to něco relativně nového, takže se určitě objeví i nové chyby a problémy.

Jinak sbližování desktopu a serveru je to, co mi na Linuxu přijde úplně nejlepší. Já třeba na testovacích nebo nově instalovaných serverech s velkou výhodou využívám jinak spíš desktopové vlastnosti typu multicast DNS, link-local IPv6 a další.

Udržovat na server jiný init systém mi přijde škoda.

[Radek Hladik]

Říkejte si o mně, že jsem konzerva, ale zrovna tuhle novinku moc nevítám Asi se stanu členem vývojového týmu a budu nenápadně škodit, ať se to nikdy nevydá ( a patentuju si guerilla developmnet)

Takyže jsi konzerva :).

Myslím si, že logování nikdo nezatracuje, a failed služby budou úplně stejně failed jako dřív. Běžící aplikace zahlásí, že nedostala data ze sockety, o poruchové aplikaci init program zahlásí, že se ji nepodařilo spustit a ona sama pravděpodobně někde vypíše konkrétní důvod.

Chápu, že logování nikdo nezatracuje. Ale teď to funguje tak, že pokud služba nenaběhne, tak výpíše zhruba jednořádkový důvod přesně v tom místě, kde se měla spustit. A pak se v logu dohledají detaily. Ale když se mi teď nastartuje jen socket a až za x času se zjistí, že aplikace, která ho má zpracovávat nenabíhá?

Starting MySQL [OK]
Starting httpd [OK]
Starting readaehad_early MySQL datadir read failed. Aborting abnormally[OK]
Stopping httpd [ok]
Service MySQL [Failed]

Vypadá to tak nemožně?

Píšu jen svůj pohled na to, jak by to mělo vypadat. Je to něco relativně nového, takže se určitě objeví i nové chyby a problémy.

Jinak sbližování desktopu a serveru je to, co mi na Linuxu přijde úplně nejlepší. Já třeba na testovacích nebo nově instalovaných serverech s velkou výhodou využívám jinak spíš desktopové vlastnosti typu multicast DNS, link-local IPv6 a další.

Některé ty novinky, se mi, po zralém ozkoušení (konzerva ), líbí taky. Ale tahle zrovna ne. A to sbližování, to se mi taky líbí, ale jen do chvíle, kdy to není válcování

Udržovat na server jiný init systém mi přijde škoda.

No to mně právě taky, ale tenhle mně děsí.

[pavlix]

Tak mě popravdě nadchla už Lennartova přednáška na Fosdemu :).

K těm chybovým hláškám... já nevím, jak je to teď přesně uděláno, či jakým směrem se to bude dál vyvíjet. Popravdě řečeno na tom záleží nejvíc.

Opět podle mého osobního názoru, dobře postavená služba by neměla selhat jen proto, že selže služba, na které závisí. Vím, je to pustá teorie. Například, služba, která ke své funkci potřebuje databázi by podle mě neměla selhat jen proto, že databáze je down.

Na té službě přece nic pokaženého není, takže nevidím důvod, proč by se neměla spustit a setrvat v pasivním stavu. Později přijde chybová hláška ohledně databáze (případně si i aplikace všimne, že s databází je problém a zaloguje ho též). Administrátor opraví problém s databází, pustí databázi a aplikace může navázat spojení a následně přejít do aktivního stavu bez dalšího restartu.

Takže si myslím, že problém není v samotném systemd, ale v tom, že se s ním budou muset vývojáři a balíčkáři teprve naučit pracovat.

[l4m4]

Pokud služba potřebuje databázi, tak bez databáze nelze tuto službu používat. Tudíž nemá bez databáze právo tvdit, že je úspěšně spuštěna, to by byla zjevná lež.

Úspěšně se může spustit leda služba, která databází volitelně využívá.

[Heron]

Služba, která ke své činnosti databázi potřebuje se ovšem také musí umět vyrovnat s odpojením od databázového serveru (z důvodu například krátkodobého výpadku síťového spojení, restartu databázového serveru apod.) za provozu. Toto bych do jejího spouštění netahal, ta služba se může (z hlediska initu) spustit korektně i bez DB.

Navíc bylo by velkou chybou, kdyby byla v init skriptu definována závislost takovéto služby na databázi jakožto lokální službě. Databáze může být kdekoliv na síti.

[pavlix]

Služba, která ke své činnosti databázi potřebuje se ovšem také musí umět vyrovnat s odpojením od databázového serveru (z důvodu například krátkodobého výpadku síťového spojení, restartu databázového serveru apod.) za provozu. Toto bych do jejího spouštění netahal, ta služba se může (z hlediska initu) spustit korektně i bez DB.

Tak na tom se perfektně shodneme.

Navíc bylo by velkou chybou, kdyby byla v init skriptu definována závislost takovéto služby na databázi jakožto lokální službě. Databáze může být kdekoliv na síti.

Taky dobrá poznámka.

[pavlix]

Ona ta služba ale je spuštěna :). Je to proces v systému, který nehavaroval, nýbrž čeká na spuštění spolupracujícího procesu, což je naprosto legitimní stav.

To je právě ono... pokud se díváš na systemd pohledem sekvenčního spouštění služeb, tak ho nepochopíš.

Jako příklad uvedu NetworkManager, ten přece taky hlásí, že je úspěšně spuštěný, i když neplní svoji funkci (například jsi ještě nezapojil zařízení, přes které chceš připojení realizovat).

Úspěšně se může spustit leda služba, která databází volitelně využívá.

To záleží na tom, čemu říkáš úspěšně :). Tady jde jen o to, že se služba spustí a nehavaruje, ač třeba ještě není schopná autentizovat uživatele.

[l4m4]

Neřeším vůbec jak se dívat na systemd ani sekvenční spouštění služeb. Nezáleží na tom. Jde zde pouze o základní premisu: Služba běží ⇔ službu lze využívat.

Výsledek úspěšného spuštění má být, že služba běží teď, nikoli to, že by služba možná jednou mohla běžet, nebo možná taky ne. Pokud službě odejde ta databáze po spuštění, tak se dostane do havarovaného stavu, tj. opět neběží úspěšně.

[pavlix]

Výsledek úspěšného spuštění má být, že služba běží teď, nikoli to, že by služba možná jednou mohla běžet, nebo možná taky ne.

Ona ta služba technicky běží teď. Co se týče pohledu uživatelů, ten bych do technické realizace vůbec netahal.

Pokud službě odejde ta databáze po spuštění, tak se dostane do havarovaného stavu, tj. opět neběží úspěšně.

Pokud služba při odpojení od databáze havaruje, tak je to špatná služba a bál bych se, že bude mít i další problémy. Doporučuju hlásit chyby a omlátit programátorům o hlavu.

[Radek Hladik]

Tak mě popravdě nadchla už Lennartova přednáška na Fosdemu :).

Letos jsem Fosdem vynechal, takže jsem se na tu přednášku kouknul teď. A musím říct, že mě spíš odradila:

"Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..."

"Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.

"Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..."

"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.

"Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)

[pavlix]

"Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..."

Co ti vadí na tom, že se závislosti definují pomocí funkce namísto pomocí jména? Stejně je tomu například u RPM balíčků. Mně to přijde skvělé.

"Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.

Mně se osobně tenhle styl spouštění vždycky líbil. To SSH se stejně forkuje, tak co už.

"Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..."

To vnímám jako velmi pozitivní... znamená to, že celý ten systém tak jak je znovu postavený není pomalejší, a to ještě není to spouštění není ani vyladěné. Až se to vyladí, má to teprve smysl benchmarkovat.

"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.

To píšeš tak zmateně, že to nemá cenu komentovat.

"Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)

Zrovna tohle si pamatuju jak říkal a souhlasím s ním, ale s tím, co jsi napsal ty to nemá vůbec nic společného.

[Radek Hladik]

Všecko, co jsem psal, jsou víceméně mnou shrnuté otázky a odpovědi. Většinou dokonce uznal, že je to valid point, good question nebo tak...

"Díky socket based activation nemusíme znát dependency mezi službami. Takže se nám automaticky (implicitně) ty závislosti najdou, jen musíme vědět, která služba jaké sockety potřebuje..."

Co ti vadí na tom, že se závislosti definují pomocí funkce namísto pomocí jména? Stejně je tomu například u RPM balíčků. Mně to přijde skvělé.

Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.

"Aby to fungovalo, tak se musí patchnout démoni. Případně nemusí, pokud už třeba umějí spouštění přes inetd, například sshd" - ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.

Mně se osobně tenhle styl spouštění vždycky líbil. To SSH se stejně forkuje, tak co už.

Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna.

"Jaké to mělo realné zrychlení?" "Když nám byli všichni bozi naklonění, tak tam zrychlení bylo..."

To vnímám jako velmi pozitivní... znamená to, že celý ten systém tak jak je znovu postavený není pomalejší, a to ještě není to spouštění není ani vyladěné. Až se to vyladí, má to teprve smysl benchmarkovat.

Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace).

"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.

To píšeš tak zmateně, že to nemá cenu komentovat.

Ok, více polopaticky, ikdyž v tom videu to je pěkně pochopitelné. 1) Máme tu pěknou featuru, kdy se místo fsck spustí nejprve automount na daný mountpoint a pak fsck. A až ten fsck doběhne, tak se automountpoint odmpojí a připojí skutečný FS 2) Takže například taková Samba už může běžet a exportovat /home, ale když tam zkusí přistoupit, tak se zablokuje, protože to ve skutečnosti je teprve ten automount, a až doběhne fsck, tak se to připojí normálně, samba se odblokuje a vše bude vypadat, jakoby nic... 3) Otázka z pléna: A co když to fsck poběří v řádech minut až hodin? 4) Hmmm, aha... No tak se ta samba zablokuje a protože systemd si hlídá všechno pomocí timeoutů, tak se ta samba po cca minutě odblokuje s I/O errorem. No sice samba dostane I/O error, ale je to úplně stejné jako dřív, kde ta samba vůbec po dobu toho fsck neběžela. 5) Komentář z pléna: No to rozhodně stejné není, protože z hlediska klienta se ta samba tváří jako normálně přístupná, objeví se ty shary na sítí atd... 6) Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?

"Rádi bychom fušovali do Gnome/Kde sesison managementu, ale sereme na nelinuxové OS..." (Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)

Zrovna tohle si pamatuju jak říkal a souhlasím s ním, ale s tím, co jsi napsal ty to nemá vůbec nic společného.

A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky. Takže mohou nastat cca tyto varianty: 1) KDE/Gnome/... bude mít svůj session manager a systemd ho na linuxu nahradí sebou. 2) KDE/Gnome/... přejde na systemd. Varianta 1) zcela očividně přidělává spoustu práce a ikdyby jí všechnu udělali lidi od systemd, což se mi nezdá moc pravděpodobné, tak to určitě nebude kompatibilní a bude s tím spousta problémů... Varianta 2) Jsou dvě podvarianty. Buď ostatní systémy přestanou daná prostředí používat, nebo někdo naportuje systemd na ony platfomy, což nebude jendoduché, protože celé systemd je těžce postavené na linuxových technologiích (což samo o sobě mi nevadí)

[pavlix]

Všecko, co jsem psal, jsou víceméně mnou shrnuté otázky a odpovědi. Většinou dokonce uznal, že je to valid point, good question nebo tak...

Ano, on je velice pozitivní ohledně připomínek.

Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.

Ono to tvrzení právě bylo konzistentní, než jsi ho upravil :).

Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna.

Kdo ti tvrdí, že to není velká změna (nevím, co míníš pojmem „konfigurační změna“)?

Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace).

Od fosdemu už uplynula nějaká doba, takže jsem reagoval na tvůj „přepis“, kde jsi jaksi tohle vynechal. Mimochodem, pokud si v tom jádro nechá udělat maglajs, tak hádám, že by to chtělo opravu jádra, případně to doladit (nějaké hinty pro jádro, že teď je potřeba natáhnout radši větší kus dat pohromadě, pokud je to točitý disk).

Každopádně ta rychlost je jediný bod, o který jsem se kdy bál :).

Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?

Myslím, že je to tak jednoduchá věc, že bys ji zvládl popsat jednou větou, kdybys chtěl. Prostě Lennarta napadl zajímavý use case, který se nakonec neukázal jako až tak užitečný. To mi přijde naprosto OK.

Nevidím důvod mu vyčítat, že se zmínil o tom, že systemd něco umí, a holt zvolí nedomyšlený příklad užití.

A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky.

Směšuješ podle mě dohromady dvě nesouvisející věci. Jedna je, že teď při vývoji ho vůbec nezajímá starat se o jiné systémy, protože na to prostě nemá čas. Taky říkal, že nemá problém s tím, když se do toho někdo pustí.

Jiná věc jsou jakési nápady či plány do budoucna, ale nikde na té přednášce netvrdil, že se systemd nebude v budoucnu udržovat i pro jiné systémy. Spíš naopak.

Podle mě by bylo mnohem lepší, kdybyses zaměřil na aktuální problémy systemd a ty třeba i hlásil, než hořekoval nad nějakými mlhavými plány, u kterých může trvat roky než se uskuteční nebo zavrhnou. Tedy pokud se systemd vůbec hodláš nějak zabývat.

[Radek Hladik]

Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.

Ono to tvrzení právě bylo konzistentní, než jsi ho upravil :).

No ono bylo nekonzistetní pořád. Na jednom slajdu popisoval, jak se ty závislosti najdou samy tím, že se udělají ty sockety. A říkal něco jako: "Takže není potřeba ty závislosti nijak řešit, všecko se udělá samo". A pak se ho někdo zeptal, jak systemd pozná, které sockety a jak a on dodal, že se to musí napsat do unit filu. A pak se ho někdo zeptal, jak si s tim poradí ty démoni a on řekl, že se musí opatchovat.

Mně je ve skutečnosti šumák, jestli se spouští tak, či onak. Ale ať mi nikdo netvrdí, že to není velká konfigurační změna.

Kdo ti tvrdí, že to není velká změna (nevím, co míníš pojmem „konfigurační změna“)?

On všude tvrdil, jak je to drop-in replacement, zpětně kompatibilní, nic moc to ve skutečnosti nemění, atd... "Konfigurační změna" je změna konfigurace. Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.

Ne to to neznamená. Sám říkal, že na rotačním disku to dokáže udělat pěkný maglajs a může to být i značně pomalejší. Na SSD je to pak výrazně rychlejší. SSD je budoucnost, takže je to OK. (Téměr doslovná citace).

Od fosdemu už uplynula nějaká doba, takže jsem reagoval na tvůj „přepis“, kde jsi jaksi tohle vynechal. Mimochodem, pokud si v tom jádro nechá udělat maglajs, tak hádám, že by to chtělo opravu jádra, případně to doladit (nějaké hinty pro jádro, že teď je potřeba natáhnout radši větší kus dat pohromadě, pokud je to točitý disk).

Já jsem mluvil o té přednášce. Nevynechal jsem to, pouze jsem to shrnul do "když nám byli všichni bozi naklonění", protože toho bylo trochu víc.

Každopádně ta rychlost je jediný bod, o který jsem se kdy bál :).

No, když si vezmu ty jeho úvodní slajdy se slovy jako "agresivíní paralelizace" a těmi šipkami, kdy systemd to udělá všechno v jedné šipce ostatních systémů, tak zrovna rychlost by měla být asi podstatná, ne? A podotýkám, že já chápu, že ty šipky jsou sice stejně dlouhé, ale že to ve skutečnosti poběží déle, ale on přímo říkal: "a tady už vidíte, že je to o jednu šipku kratší..." (srovníní SystemV a Upstart)

Hmmm, "thats a valid point... Well I've ran out ouf time....." Už je to jasnější?

Myslím, že je to tak jednoduchá věc, že bys ji zvládl popsat jednou větou, kdybys chtěl. Prostě Lennarta napadl zajímavý use case, který se nakonec neukázal jako až tak užitečný. To mi přijde naprosto OK.

Nevidím důvod mu vyčítat, že se zmínil o tom, že systemd něco umí, a holt zvolí nedomyšlený příklad užití.

Nejprve bych podotkl, že to nebyl usecase vymyšlený na místě na základě nějakého dotazu, ale předem připravený v rámci přednášky, takže není úplně OK, že byl špatně. Ale co je horší, to není use case, na který bych narazil, když něco udělám špatně. To je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambu. Ale ani to by nebylo nejhorší. Nejhorší je, že celá ta myšlenka je totálně nedotažená, z čehož vyplývá i to, že ten jeho use case nefunguje. A nebude fungovat spousta dalších, zatímco těch, kde to něco přinese bude pár. Protože tak, jak to popisoval, tak to přináší toto: "Pokud fsck poběží kratší dobu, než minutu, tak část té minuty ušetříme tím, že budeme spouštět věci během toho fsck a ty poběží, dokud nebudou ten kontrolovaný filesystém používat. Pokud se to do minuty stihne zkontrolovat, tak jsme něco malinko ušetřili, pokud ne můžeme nadělat šílený nepořádek.". Docela by mně zajímalo, co se stane, když tedy na /home poběží fsck a nějaká další služba bude třeba chtít projet home adresáře uživatelů, aby se podívala jestli s nimi něco nechce. Tak její start na minutu zmrzne a pak bude muset řešit I/O error.

A to právě má společného hodně. Dokonce přesně na to se ho někdo ptal a on to okecal způsobem: "I do not care about the other systems...". Problém je v tom, že dokud plánují vylepšit bootování Linuxu, tak je to ok. Ale ve chvíli, kdy mají secret vision (nebo tak nějak to říkal) nahradit session manager ve KDE/Gnome/XFCE/..., tak ty se na jiných systémech používají taky.

Směšuješ podle mě dohromady dvě nesouvisející věci. Jedna je, že teď při vývoji ho vůbec nezajímá starat se o jiné systémy, protože na to prostě nemá čas. Taky říkal, že nemá problém s tím, když se do toho někdo pustí.

Jiná věc jsou jakési nápady či plány do budoucna, ale nikde na té přednášce netvrdil, že se systemd nebude v budoucnu udržovat i pro jiné systémy. Spíš naopak.

Tak to jsem asi koukal na jinou přednášku. "The thing is, if we focus on Linux, we have so many oppurtunities and with Linux specific APIs...because Linux is the most adavanced kernel....And Linux has all the awesome things..." (cca 31. minuta toho videa z Fosdemu).

Podle mě by bylo mnohem lepší, kdybyses zaměřil na aktuální problémy systemd a ty třeba i hlásil, než hořekoval nad nějakými mlhavými plány, u kterých může trvat roky než se uskuteční nebo zavrhnou. Tedy pokud se systemd vůbec hodláš nějak zabývat.

A dokonce to jsem chtěl udělat. Ať s tím mám nějaké reálnější zkušenosti, ikdyž radši bych se tomu obloukem vyhnul, ale to se zdá nebude možné. Stáhnul jsem si Fedoru15 beta, pustil VirtualBox a bác. Google+bugzila je chytrá a hle, systém potřebuje na instalaci 1GB RAM (skoro se mi chce říct wtf: 14ce stačilo půl, ale jsem slušně vychovaný a toleratní). Nu nevadí, sice budu muset něco povypínat, ale aspoň se to nainstaluje a pak to snad půjde snížit. Instalace se mi 3x řízla při kopírování souborů (pokaždé jinde) a jednou vlastní kopírování proběhlo za 10 vteřin (kupodivu to nic nenainstalovalo )... A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemd

[pavlix]

A pak se ho někdo zeptal, jak systemd pozná, které sockety a jak a on dodal, že se to musí napsat do unit filu. A pak se ho někdo zeptal, jak si s tim poradí ty démoni a on řekl, že se musí opatchovat.

Já jsem měl to štěstí, že už jsem o systemd něco věděl, takže jsem jeho vyjádření pochopil tak jak je myslel.

Možná se nevyjádřil přesně, on vůbec nepůsobí jako lektor či řečník, spíš jako programátor, který umí mluvit hlavně na své úrovni abstrakce. Já jsem mu v technickém smyslu rozuměl, takže jsem v tom nekonzistenci ani neviděl.

Nicméně na funkci systemd to nic nemění, ani kdyby se v něčem při přednášce vyloženě seknul.

Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.

Ono ti může být jedno, jak moc komplikovaná je migrace na systemd, když ji za tebe stejně provedou tvůrci distribuce.

No, když si vezmu ty jeho úvodní slajdy se slovy jako "agresivíní paralelizace" a těmi šipkami, kdy systemd to udělá všechno v jedné šipce ostatních systémů, tak zrovna rychlost by měla být asi podstatná, ne?

Konceptuálně ano, ale otázka je, jestli je systemd dostatečně vyladěný, a jestli jeho konfigurace v dané distribuci je dostatečně vyladěná, případně jestli nějaký software nedělá vyložené nesmysly vzhledem k paralelnímu spuštění.

Tzn, nevím, jestli už nadešel správný čas na benchmarky, jestli není příliš brzo.

To je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambu

Podle toho, jestli správci balíku takovou změnu provedou. Pokud vím, tak systemd to pouze umožňuje, nevyžaduje.

A nebude fungovat spousta dalších, zatímco těch, kde to něco přinese bude pár.

To si povíme, až to bude pár let v běžných distribucích. Zatím se prostě holt lišíme názoru na výsledek, který ještě není vidět.

Tak to jsem asi koukal na jinou přednášku.

Spíš mám pocit, že vidíš rozpory tam, kde já žádné nevidím :). Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu.

A já nevidím jediný důvod, proč by se Lennart měl nějak speciálně zabývat dalšíma platformama.

A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemd

Nojo... tak když se ti nepodaří ani dotáhnout instalace :). Neříkám, že je to tvoje vina, ale já už používám Fedoru 15 cca měsíc.

[Radek Hladik]

Nicméně na funkci systemd to nic nemění, ani kdyby se v něčem při přednášce vyloženě seknul.

Ale už o několik příspěvků výše píšu, že reaguju na tu přednášku. Ta je pro mně něco, co mně má přesvědčit/seznámit/ohromit/... a to se jí vůbec nepovedlo.

Pokud se při správě stroje používaji postupy jako configuration management, change management, pak je to i docela netriviální proces.

Ono ti může být jedno, jak moc komplikovaná je migrace na systemd, když ji za tebe stejně provedou tvůrci distribuce.

To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd... Neříkám, že je to můj přístup, ale znám organizace, kde se na každou konfigurační změnu dělá opravdu postup typu: návrh změny->analýza dopadu->návrh backup postupu->vyzkoušení->nasazení... Například: V sshd(8) se dočteme: sshd is normally not run from inetd because it needs to generate the server key before it can respond to the client, and this may take tens of seconds. Clients would have to wait too long if the key was regenerated every time. However, with small key sizes (e.g. 512) using sshd from inetd may be feasible. Je snadné říct, že dneska jsou CPU tak rychlé, že už to není pravda. Ale je to opravdu tak? A co když se přihlásí najednou x klientů? Takže pokud by se jednalo o nějaký opravdu důležitý sýstém, který podléhá tomu, co píšu výše, tak bude muset někdo sednout a zjistit, jak to s tím je. A to za mně ten autor distirbuce neudělá... A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.

To je zásadní změna, která se dotkne všech, kteří si prostě nainstalují sambu

Podle toho, jestli správci balíku takovou změnu provedou. Pokud vím, tak systemd to pouze umožňuje, nevyžaduje.

Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to děje

Spíš mám pocit, že vidíš rozpory tam, kde já žádné nevidím :). Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu.

Ale zároveň se naprosto jasně vyjádříl ve smyslu, že ho to nezajímá a že tomu nemíní nijak napomáhat a chce striktně využívat Linux only věcí...

A já nevidím jediný důvod, proč by se Lennart měl nějak speciálně zabývat dalšíma platformama.

Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde. Je to cca 30. minuta na tom videu, přesně ten dotaz a jeho komentář ve stylu: "chceme nahradit sesison management v (něčem, co neběží jen na linuxu) (něčím, co beží jen na linuxu)".

A tak jsem šel radši pálit čarodejnice a maso, než laborovat se systemd

Nojo... tak když se ti nepodaří ani dotáhnout instalace :). Neříkám, že je to tvoje vina, ale já už používám Fedoru 15 cca měsíc.

Fedoru používám ještě od doby, kdy to ani Fedora nebyla. Dokonce ani Fedora Core. A mám pocit, že už jsem si se s ní vcelku "sčuchnul" a umím s ní dělat docela psí kusy. Ale přiznám se, že dvě hodiny neúspěšných instalací, to se mi ještě nestalo... A ač si myslím, že to moje chyba není, tak prostě zatím systém nainstalovaný nemám. Ale až bude zase chvíli nálada, tak se k tomu zkoušení vrátím, protože ať chci nebo nechci, tak pokud se Fedora 16 neodvrátí od Systemd, tak se s ním budu muset poprat...

[pavlix]

Ale už o několik příspěvků výše píšu, že reaguju na tu přednášku. Ta je pro mně něco, co mně má přesvědčit/seznámit/ohromit/... a to se jí vůbec nepovedlo.

Mně ta přednáška se seznámením trochu pomohla, i když daleko víc pomohly Lennartovy texty. Ale já samozřejmě můžu psát jen za sebe, že.

To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd...

Fajn, aspoň budu mít větší cenu na trhu práce, stejně jako s náskokem v IPv6 :).

A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.

To katastrofické scénáře hodné teoriím o zničení veškeré výpočetní elektroniky rokem 2000.

Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to děje

Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde.

Upřímně? Je mi to jedno, kdo z nich to bude. Ale správce systemd obvykle do konfigurace samby svévolně zasahovat nebude. Já nejsem v balíčkování distribucí nijak zběhlý, ale z toho mála co vím lze vyvodit, že akorát vymýšlíš blbosti. Stačí se podívat, který soubor kterému balíku náleží.

Ale zároveň se naprosto jasně vyjádříl ve smyslu, že ho to nezajímá a že tomu nemíní nijak napomáhat a chce striktně využívat Linux only věcí...

A já přesně tomuto přístupu fandím a nevidím v tom žádný rozpor s tím, že jiní můžou zajistit, aby systemd běžel na jejich oblíbené platformě.

Ani já ne. Ale pak nemá chtít nahradit něco, co se používá i všude jinde.

Nechápu, proč mu vyčítáš, že hledá další možná nasazení systému, na kterém pracuje. Mě to přijde naprosto normální a přirozené.

Ale přiznám se, že dvě hodiny neúspěšných instalací, to se mi ještě nestalo...

Mě taky ne. Ale hlavně že za to může zrovna systemd.

[Michal Vyskočil]

To zdaleka není pravda. Počkej, až s tím Redhat přijde v Enterprise Linuxu. Pak se ta drobná změna bude muset objevit ve všech dokumentacích, budou to muset znát lidi na podpoře, atd... Neříkám, že je to můj přístup, ale znám organizace, kde se na každou konfigurační změnu dělá opravdu postup typu: návrh změny->analýza dopadu->návrh backup postupu->vyzkoušení->nasazení... Například:

No tak zrovna RHEL 6 má upstart a předpoklad je, že RHEL 7 bude se systemd, takže organizace budou muset přejít. Nicméně pro opravdu velké nasazení se používají věcičky jako puppet, takže je to spíše otázka integrace systemd s těmito konfiguračními nástroji.

A to nemluvě o tom, že třeba na tom stroji běží přes SNMP monitoring procesů a hle, najednou nám neběží SSH démon.

Tak znovu, že systemd něco umí neznamená, že takové nastavení je rozumné.

Ovšem správci kterého balíku? Systemd nebo samby? Správce systemd balíku to povolí a lidi od samba balíku budou akorát koukat, co se to děje

Pokud jde o možnost upravovat si systemd jednotky, tak toto je další výhoda systemd oproti klasickým skriptům. Systemd bere konfiguraci s /lib a z /etc, přičemž ten druhý je prioritní a určen pro uživatelské úpravy.

V praxi to znamená, že si můžeš upravit libovolný "init skript" a být bez obav, že update balíčku změny zase vrátí zpět.

Pokud vím, tak během té samé přednášky řekl, že nemá žádný problém s tím, když někdo bude portovat systemd na jinou platformu.

Zajímalo by mě, kolik zastánců různých platforem je skutečně používá.

Systemd je Linux only věc, stejně jako launchd je OS X only, nebo SMF je Solaris only. Port na jinou platformu je prakticky nemožný, protože je systemd pevně zadrátovaný s Linuxem - třeba jmenné soubory procesu, různé plánovače, nebo třeba cgroups a ostatní věcičky. Tohle všechno by se muselo na další platformu přenést a vlastně proč z ní dělat druhý Linux ...

[pavlix]

Tak já osobně nevidím problém v tom přenést systemd na jinou platformu, pokud ta platforma doimplementuje vše potřebné.

Druhý linux... erm, diverzita je nějakým způsobem přirozená, pak taky je tu možnost, že Linux nebude ultimátní platforma na věky věků, že :). Nevidím důvod, proč by si někdo nemohl udělat třeba i nové experimentální jádro, které poskytne všechny prostředky k poskytování systemd. Třeba některé z takových experimentálních jader časem získá pozici na trhu.

Ok, je to teorie, chápu, že tě něco takového příliš nezajímá, ale nejde vyloučit, že se někomu možnost kombinovat systemd s jiným jádrem bude líbit.

[Heron]

Jenom takovou malou OT poznámku:

Pokud fsck poběží kratší dobu, než minutu

Opravdu bych chtěl vidět FS, který se při dnešních velikostech disků, bude kontrolovat (tím je myšlena úplná kontrola, ne kontrola na clean umount) pouze minutu.

[michich]

Já jen poukazuji na nekonzistenci tvrzení: Závislosti se nám najdou samy. Teda musíme tomu dodat nějaké nové informace. Jo a musí se ty démoni opatchovat.

Tady vidím nedorozumění. Existují dvě kategorie závislostí, které jsou navzájem nezávislé (Lennart vždycky říká, že jsou ortogonální): potřeby (requirements; Requires, Wants) a řazení (ordering; Before, After).

Vytvořením soketů předem se automaticky vyřeší pouze problém řazení.

Je pravda, že démoni, kteří mají umět soketovou aktivaci využít, musí být pro tento účel opatchováni. Soketová aktivace ale není povinná. Pokud démon není takto opatchován, musí se holt pouštět klasickým způsobem a řazení musí být pak uvedeno ručně (Before=... nebo After=... v unit souboru, LSB hlavičkou v initskriptu, nebo pořadovým číslem v SysV symlinku).

[Radek Hladik]

Tady vidím nedorozumění.

To není nedorozumění, já jsem to plně pochopil. Ale jak píšu výše, mám za to, že si tím protiřečí.

[pavlix]

Ale jak píšu výše, mám za to, že si tím protiřečí.

A já mám za to, že vůbec :).

[michich]

Zkusím to popsat ještě na příkladu. Dejme tomu, že máme tři daemony spravované jako systemd služby: A.service, B.service, C.service.

A.service ke svému provozu nic dalšího nepotřebuje a poskytuje své služby na UNIX soketu A.socket.

B.service ke svému běhu vyžaduje pomoc od A.service (Mluví s ní přes A.socket; Není nutné, aby tahle informace byla někde výslovně uvedena.) B.service poskytuje zase své služby na soketu B.socket.

C.service dokáže využít služeb B.service (mluví s ní přes B.socket), ale v omezeném rozsahu dokáže fungovat i tehdy, když B.service není nainstalovaná nebo zapnutá.

Administrátor zapne všechny tři služby. (Při zapínání služeb A.service a B.service budou zároveň zapnuty i odpovídající unity soketů A.socket a B.socket.) Po restartu systemd vytvoří A.socket a B.socket. Potom systemd spustí všechny tři služby najednou. Vůbec přitom nepotřebuje vědět o těch vzájemných závislostech. Nezáleží ani na tom, který daemon startuje rychleji. I kdyby C.service byl nejrychlejší, tak při pokusu o čtení z B.socket ho kernel uspí, dokud tam nepřijdou data od B.service. Totéž platí pro vztah mezi B a A.

Později se administrátor rozhodne, že B.service nechce, tak ho vypne. (Tím se vypne i B.socket.) Po restartu systemd vytvoří A.socket. Potom spustí A.service a C.service najednou. Ty spolu nijak nekomunikují, takže najedou tak rychle, jak to zrovna vyjde. C.service se někdy během startu pokusí připojit na B.socket, což ihned selže, a tak poběží v omezeném rozsahu.

V obou případech nastartovaly služby tak rychle, jak to šlo, a přitom nikde nemusela být explicitně uvedena informace o vzájemných vztazích mezi A, B, C.

[Radek Hladik]

Ano tomu rozumím. Řekněme, že místo service.C potřebuje service.A, říkáme, že že service.A poskytuje něco. A service.C toto něco potřebuje, což se nikde nezapisuje. Vlastní hledání závislostí pak řeší systém poloautomaticky, tedy část těmi sockety a další část tím, že administrátor nastaví, co se má spouštět.

Jinak řečeno podle tvého příkladu máme administrátora, který musí vědět, že mezi C a A existuje závislost, protože musí nastavit A, aby se spouštělo (vytvořil se socket).

Ale opět opakuju, ten mechanismus se mi z "hlediska elegance" líbí, ale já preferuju si to udělat ručně. Ale hlavně jsem poukazoval na to, že na té přednášce tvrdí, že se ty závislosti samy najdou a nemusí se nic nastavovat, jen se musí nastavit to, jaké sockety která služba nabízí...

[m;)]

takze sa linux dostal do pozicie, ktora mu tak vadi(la) na windows -- neberie ohlad na (mensie) alternativne systemy .. :-/

[pavlix]

takze sa linux dostal do pozicie, ktora mu tak vadi(la) na windows -- neberie ohlad na (mensie) alternativne systemy .. :-/

To mi zní jako dva nesmysly v jedné větě. Nevím, koho přesně myslíš tím linuxem, když píšeš, že mu něco vadilo.

A že nebere ohled? Zase kdo nebere ohled? Lennart? Torvalds?

Pokud někdo bude chtít portovat systemd na svou oblíbenou platformu, způsob jistě najde.

[michich]

ať mi nikdo neříká, že to není pořádná změna změnit spouštění SSHD z procesu, co si sám řídí sockety, do inetd režimu.

No změna to je, ale není nutné zrovna tuhle možnost využívat. Výchozí způsob spouštění sshd ve Fedoře 15 je stále ten původní (tedy že sshd si naslouchající soket dělá sám).

"Dokonce to umí, že než se provede fsck, tak je tam automount point a když k němu někdo přistoupí, tak se to zablokuje, dokud fsck nedojede. A vždyť je to shodné, jako teď. Teď vám ta samba hodinu nepoběží vůbec, zatímco se systemd vám poběží, ale na hodinu se zablokuje. Respektive po minutě to vyhodí I/O error a samba vrátí I/O error..." Jestli je tohle stejné chování z pohledu klienta, tak já jsem papež.

Tohle je zas o tom, že systemd něco nového umí, ale výchozí nastavení to není. automounty ti to vyrobí, pokud si do /etc/fstab přidáš volbu comment=systemd.automount. V F15 to běžně není.

(Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)

To jeho nadužívání toho slova v přednáškách se mi taky nelíbí.

[Radek Hladik]

No změna to je, ale není nutné zrovna tuhle možnost využívat. Výchozí způsob spouštění sshd ve Fedoře 15 je stále ten původní (tedy že sshd si naslouchající soket dělá sám).

Zrovna v tomhle případě mi je jedno, jak to to SSHd spouští. Ale u jiných věcí mi to jendo být nemusí a jsem rád, že se ve Fedoře k tomu staví konzervativněji

Tohle je zas o tom, že systemd něco nového umí, ale výchozí nastavení to není. automounty ti to vyrobí, pokud si do /etc/fstab přidáš volbu comment=systemd.automount. V F15 to běžně není.

Jenže jak už jsem psal výš, to není jen o tom, že to něco nového umí. Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů. A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouho

(Schválně používám tento expresivní výraz, aby korespondoval s tím jeho často používaným shitload...)

To jeho nadužívání toho slova v přednáškách se mi taky nelíbí.

Mně se upřímně řečeno nelíbíl téměř celý jeho styl projevu, zavádějící slajdy, poměrně arogatní chování a možná bych řekl i ne zrovna dobře provedená (nebo aspoň špatně odprezentovaná) práce. A to jsou věci, které mi vadí u lidí, kteří mi chtějí měnit způsob, jak mi startuje systém

[michich]

Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů.

Ty víš, co všichni uživatelé potřebují? Já si umím představit, že si to zapnul pro disk, na kterém mám hudbu, aby mi občasný fsck spouštěný na tomto oddílu nezdržoval přihlášení do Gnome.

A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouho

Nevím o tom, že by to vůbec někdy mělo být defaultně.

[Radek Hladik]

Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů.

Ty víš, co všichni uživatelé potřebují? Já si umím představit, že si to zapnul pro disk, na kterém mám hudbu, aby mi občasný fsck spouštěný na tomto oddílu nezdržoval přihlášení do Gnome.

Samozřejmě, že nevím co chtějí všichni uživatelé. Ale několik jich znám a vím, že by mě s tímhle vyhnali... A ano myšlenka s tím fsck hudby, aby nebrzdil start gnome, to zní pěkně. Jen se obávám, že to tak idylické nebude. Napadá mně spousta šílených scénářů, ale třeba je to jen mou bujnou fantazií

A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouho

Nevím o tom, že by to vůbec někdy mělo být defaultně.

A já právě doufám, že to tak zůstane co nejdéle...

[Michal Kubeček]

A ano myšlenka s tím fsck hudby, aby nebrzdil start gnome, to zní pěkně. Jen se obávám, že to tak idylické nebude.

Nebude. Většina lidí má jeden disk, takže fsck čehokoli na něm dokáže efektivně přidusit zbytek systému.

[pavlix]

Zrovna v tomhle případě mi je jedno, jak to to SSHd spouští. Ale u jiných věcí mi to jendo být nemusí a jsem rád, že se ve Fedoře k tomu staví konzervativněji

Tak ona se každá experimentální možnost nemusí hned použít v živé distribuci, že.

Jenže jak už jsem psal výš, to není jen o tom, že to něco nového umí. Celá ta vlastnost je naprosto příšerně navržená bez ohledu na potřeby uživatelů. A doufám, že to ve Fedoře nebude defaultně zapnuté poměrně dlouho

On to uživatel často ani nemusí poznat, natož aby mu to bránilo naplňovat své potřeby.

Mně se upřímně řečeno nelíbíl téměř celý jeho styl projevu, zavádějící slajdy, poměrně arogatní chování a možná bych řekl i ne zrovna dobře provedená (nebo aspoň špatně odprezentovaná) práce. A to jsou věci, které mi vadí u lidí, kteří mi chtějí měnit způsob, jak mi startuje systém

Zas na druhou stranu, on není ten, kdo ti mění způsob, jak ti startuje systém. On jenom tvoří nástroj pro to jiné startování, pokud mi něco neuniklo.

[Radek Hladik]

Zas na druhou stranu, on není ten, kdo ti mění způsob, jak ti startuje systém. On jenom tvoří nástroj pro to jiné startování, pokud mi něco neuniklo.

Samozřejmě, že je to trochu zkratka z mé strany. On vytváří systém startování, který se zdá bude můj oblíbený distributor používat a protože se jedná o poměrně zásadní věc, tak se nedá moc očekávat, že budu mít jinou volbu, jakmile se onen zmíněný distributor rozhodne jeho výtvor používat. Samozřejmě kromě totálního řešení v podobě změny distributora, což je trošku overkill.

[Michal Kubeček]

Samozřejmě kromě totálního řešení v podobě změny distributora, což je trošku overkill.

A navíc je tu riziko, že to nepomůže, protože ostatní přejdou na systemd taky.

[Michal Vyskočil]

Tak pořád tu ještě bude Ubuntu s upstart

[michich]

IMHO to takhle fungovat nebude, spíše naopak. Tedy, že budeš chtít nastartovat ssh a ono to automaticky ještě předtím nastartuje síť (pokud nebyla).

Ani tak to není. Pánové, doporučuji vám prostě si to vyzkoušet, protože celá tahle debata je o tom, že všichni jenom spekulují o tom, jak by systemd mohlo fungovat, kdyby to bylo udělané špatně.

[michich]

* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

systemd žádné automatické zastavování služeb při nepotřebnosti nedělá.

Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...

Co třeba možnost zjištění, ke které službě patří daný proces a obráceně, spolehlivé zabití neposlušné služby, či dohled nad tím, že služby běží?

Z různých důvodů jsme vybrali řešení, kde server, který by rád kontrolu disku, nahodí síť, spustí ssh a pošle maíl. Admin se přihlásí, opraví a voila. Půjde toto udělat v systemd?

systemd před přimountováním oddílu spouští službu fsck@DEVICE.service. Co má ta služba dělat, je definováno v odpovídajícím unit file. Ten se dá přebít unit filem stejného jména v /etc, takže klidně můžeš spouštět místo výchozího helperu systemd-fsck nějaký svůj oblíbený shell skript.

[pavlix]

systemd žádné automatické zastavování služeb při nepotřebnosti nedělá.

Ale D-busem startované služby se při nepotřebnosti můžou samy ukončit, ne?

[michich]

To se ale ukončují samy z vlastní vůle. Není to systemd, kdo iniciuje jejich ukončení.

[pavlix]

Jojo, chápu, taky to neříkám jako argument proti systemd, jen se snažím prohlubovat znalost toho, jak celý ten systém drží pohromadě.

[Radek Hladik]

Je pravda, že zatím nad tím čistě filozofuju, protože v akci jsem to ještě neviděl. To proto, že zatím čekám, až to nějaká distribuce udělá opravdu pořádně. To se zdá, že bude v té Fedoře 15. Ale jak jsem psal, obávám se, že i když se mi to nebude líbít, tak nebude alternativa.

[pavlix]

Podle mě se dalo už delší dobu očekávat, že D-bus proroste až k samotnému spouštění služeb... co mě zaujalo, že se stejné postupy dají aplikovat bez D-busu, takže proti konceptu systemd vůbec nic nemám.

Pokud se mi hodně nebude líbit jak to funguje, bude to nejspíš kvůli bugům, které budu hlásit do bugzilly a doufat v jejich opravení.

[michich]

Jo, nějaké chyby se ještě nepochybně objeví. Za jejich nahlášení předem děkuji.

[Michal Vyskočil]

* Závislosti mezi službama - až budu mít server, kde zatím nepoběží jiná síťová služba než SSH a při restartu SSH mi to shodí síť s tím, že jí nikdo nepotřebuje, tak to asi rozmlátim

Lennart se vždy vyslovoval poměrně zdrženlivě k možnosti automatického vypínání z důvodu nečinnosti.

* Nějaké dočasné sockety, než se služba spustí - ok, mám službu, třeba webserver. Všichni klienti se určitě potěší, když se na něj budou moct připojit o vteřinu dříve. Sice jim to nebude fungovat, ale aspoň už budou "připojený". Jinými slovy, zbytečná práce navíc, která ještě může přinést komplikace.

No pro webserver to skutečně není nijak rozumné nastavení. Naštěstí systemd odložené spuštění nevynucuje, je jednoduché nastavit webserver tak, aby se daná služba spouštěla okamžitě.

Ono to dává v některých případech smysl (cups na mém notebooku) a někdy ne (cups na tiskovém serveru). Se systemd si můžete vybrat.

Zajímalo by mně, zda v serverovém použítí existuje jakýkoliv přínos celého molocha systemd oproti sadě pár skriptů, které jsou snadno čitelné, pochopitelné a člověk přesně ví, co dělají...

Tak mimo integrace s cgroups nabízí systemd poměrně bohatou škálu různých ladících knoflíků jádra a nastavení, z nichž některé nejsou z prostředí shellu vůbec dostupné.

Další výhodou je třeba to, že se služby spouštějí stejným předpisem nezávisle na způsob aktivace a nedochází k duplikaci, jako s (x)inetd.

[Petr Ježek]

Vyzkoušel jsem, žádný problém, boot s grub2 a ext2 o něco rychlejší než s původním initem. V archu je to snadná úprava v kernel line (resp. pro GRUB_CMDLINE_LINUX) s uvedením path, arch má také pro systemd pěknou wiki včetně ladění... Začínám mít pocit, že jde o solidní počin.

[Michal Kubeček]

Pořád tajně doufám, že než se tohle šílenství dostane do distribucí, zvítězí zdravý rozum. Ale jsem čím dál pesimističtější…

[Ladislav Hagara]

Příloha:

• usftZ.png (97250 bytů)

Dostal jsem obrázek.
Lennart Poettering's approach of software comparison

[Radek Hladik]

Trefné.

[Michal Kubeček]

Děkuji, je to naprosto výstižné vyjádření mých pocitů z té tabulky. Ale abych nebyl nespravedlivý, většina podobných "srovnávacích" tabulek trpí ve větší či menší míře podobným neduhem.