Názory k článku Nebojte se systemd: zbývající typy jednotek

To, co popisujete, ale není problém SystemD, nýbrž problém toho, že se spoustu let na správu služeb v Linuxu kašlalo a lepilo se to různými rovnáky na vohejbáky. SystemD se teď snaží tyhle rovnáky na vohejbáky odstranit – což samozřejmě znamená nekompatibilní změny, protože rovnák na vohejbák nemůžete spravit tím, že k tomu přidáte další vohejbák. Úplně stejně by to bylo s jakýmkoli jiným systémem, který by chtěl správu služeb udělat pořádně.

Druhá možnost by byla dělat to postupně, po malinkých krůčcích. Vzít jeden rovnák na vohejbák, vedle něj postavit o něco rovnější alternativu, která by pořád byla napojená na ostatní rovnáky na vohejbáky, a čekat několik let, než na to všichni přejdou, aby bylo možné ten jeden rovnák na vohejbák odstranit. Tohle zkoušely jiné „nové inity“, jenže to nikam nevedlo – protože s přechodem stejně byly problémy (nikdy se to staré zprasené řešení nepodařilo emulovat úplně stoprocentně), ale moc výhod to nepřinášelo (protože tam bránily ty jiné rovnáky na vohejbáky). Pak konečně někomu došlo, že tohle není cesta, že jediná možnost je do toho říznout a udělat to rovnou celé pořádně – přechod sice bude bolet, ale nebude to na desítky let.

Že to bylo správné rozhodnutí je jasné už teď, svědčí o tom to, kolik distribucí už na SystemD přešlo a to, že možnosti, které přináší SystemD, začínají aplikace využívat, i za cenu toho, že se na SystemD stávají závislé. Spousta lidí na SystemD nadává, přičemž drtivá většina z nich nadává na všechno nového a na všechno, na co je moderní nadávat. Stačí si přečíst tuhle diskusi, kolik lidí na SystemD nadává, přitom ho nepoužívají a „argumentují“ výmysly a nesmysly. Vedle nich je pak hrstka těch, kteří mají sice oprávněné námitky, ale vedle systemd-haters není jejich hlas slyšet. A pořád platí, že ty oprávněné námitky je lepší převtělit do patchů, protože podporovat systemd-haters v diskusích je k ničemu. Pokud si někdo myslel, že se při vymetání toho chléva současné správy služeb nezašpiní a všechno bude čisťounké a uhlazené, tak je prostě naivní – náhrada novým řešením se dělá právě proto, že to staré je špatné a neudržovatelné, a jakýkoli pohyb okolo znamená, že se zašpiníte.

Ad není to production ready – není to tak dávno, co se jako výhoda opensource uvádělo to, že se nové verze vydávají často, takže si někde někdo potajmu několik let nepíše svůj geniální software, který pak vydá a zjistí se, že je k ničemu. Místo toho časté vydávání umožňuje rychle reagovat na změny a na problémy, na které se přijde až během používání.

Problém všech těchto diskusí je klasický. Jeden o voze, druhý o koze. Někdo na systemd něco kritizuje a hned přispěchá někdo jiný a prohlásí, že správu služeb bylo nutné vyměnit. Ano, spousta lidí si myslela, že init / rc je nutné vyměnit, přišel systemd, nahradil init / rc a spousta lidí byla spokojena, jak mají krásný nový init systém. A třeba si i mysleli, že u toho zůstane. Jenže háček už se zasekl a z původní náhrady init / rc se postupně stává náhrada všeho.

Takže otázka: jak souvisí správa služeb třeba právě s tím .device a .mount?

PS: Po dnešní diskusi mám velmi nepříjemný pocit, že se časem dočkáme systemd-filesystemd a filesystemctl a fstab bude označen jako obsolete a zrušen. Pokud tady někomu přišla reakce systému, tak, jak jsem ji popsal, normální, tak jistě není první, koho to napadlo a za pár verzí to tam máme.

Zařízení i datová úložiště jsou jen další typy služeb. To, že se starší inity tváří, že se jich to vůbec netýká, právě způsobuje nutnost používat různé rovnáky na vohejbáky. To není náhrada všeho, to je implementace toho, co správce služeb dělat má.

Aha, tak to jo no :-D Koukám, že už ty diskuse nejsou co bývaly. Na abclinuxu nějaký zoufalec do omrzení opakuje "když si to trh přeje" a teď se dočkám odpovědi, že je to prostě služba (bez dalšího vysvětlení, proč si někdo myslí, že je to služba). Tak jo.

Ale nedá mi to, fakt by mě zajímalo, co přesně za problém způsobovalo to, když během bootu nastartovaly všechny potřebné block device a podle fstabu se automaticky připojilo, co bylo nakonfigurované. Co je na tom potřeba ohýbat (nebo rovnat, nebo co s tím ten systemd vlastně dělá).

Nenapadlo mne, že je nutné vysvětlovat, proč je to služba. Někdo jiný to využívá, může to záviset na dalších službách, další služby na tom mohou záviset, v průběhu běhu systému služba může být zahájeno poskytování té služby a může být ukončeno.

Ten váš popis zacházení s přípojnými body například vůbec neřeší připojování a odpojování zařízení za běhu, neřeší uživatele (když uživatel sedí u PC a připojí k němu flash disk, chce ho mít dostupný pod svým účtem), neřeší připojování síťových úložišť (která je potřeba připojovat až po zprovoznění sítě). Ano, na všechno z toho existují nějaké workaroundy. Ale jakou výhodu má používání těch workaroundů?

Upozorňuji, že se bavíme o statickém device, kde je fs, který je očekáván od startu počítače. Tohle ale na druhou stranu krásně ukazuje přístup systemd. Protože je (asi, podle někoho) nějaký problém s flashkama, tak rovnou rozbijeme všechno ostatní.

Ten váš popis zacházení s přípojnými body například vůbec neřeší připojování a odpojování zařízení za běhu

Ano, neřeší. Není žádný důvod, aby řešil. Pokud si admin chce připojit nějaké block device za běhu, tak asi ví co dělá a příslušný mount, nebo pvscan, anebo mdadm -A, nebo luskOpen nebo btrfs device scan nebo cokoliv, si prostě sám spustí, kdy potřebuje.

neřeší připojování síťových úložišť (která je potřeba připojovat až po zprovoznění sítě)

To, kupodivu, také nebyl nikdy problém. Pokud nějaký automaticky mountovaný fs ve fstabu vypadal jako NFS, tak se, po spuštění sítě, prostě spustila služba, která jej připojila. Jestli je to workaround, nevím. Možná, aby to někoho nedráždilo, se to mohlo oddělit na fstab a netfstab. Nebo si to dotyčný admin může dát do autofs. Ne, místo toho, bylo opět potřeba rozkopat něco, co fungovalo.

Upozorňuji, že se bavíme o statickém device, kde je fs, který je očekáván od startu počítače.
O tom se bavíte vy. Já nevidím jediný důvod, proč by se souborový systém na trvale připojeném lokálním zařízení měl připojovat nějak jinak, než souborový systém na dočasném nebo síťovém zařízení.

Tohle ale na druhou stranu krásně ukazuje přístup systemd.
Ano, ukazuje to přístup systemd. Je nějaký důvod, proč řešit lokální souborové systémy zvlášť, síťové souborové systémy zvlášť, dynamické připojování a odpojování souborových systémů zvlášť? Ano, je – vždycky se to tak dělalo, protože to jinak nešlo. Věcný důvod k tomu není žádný. Je „vždycky se to tak dělalo, protože to jinak nešlo“ dostatečný důvod? Ne, není. Tak to pojďme udělat pořádně.

Protože je (asi, podle někoho) nějaký problém s flashkama, tak rovnou rozbijeme všechno ostatní.
Problém je v tom, že se jedna a ta samá věc řeší pokaždé jinak. „Rozbijeme všechno ostatní“ – nevšiml jsem si, že by to něco rozbilo. Rozbíjí se to těm, kteří to mají špatně nakonfigurované. To ale není žádná specialita systemd – když si špatně nakonfigurujete fstab, také se vám to rozbije.

Pokud si admin chce připojit nějaké block device za běhu
Jenže se nepíše rok 1970, ale 2016. K tomu, abych si připojil k počítači flashku nebo cloudové úložiště nepotřebuju admina.

Pokud nějaký automaticky mountovaný fs ve fstabu vypadal jako NFS, tak se, po spuštění sítě, prostě spustila služba, která jej připojila. Jestli je to workaround, nevím.
Ano, je to workaround. Mount musí odhadovat, jestli záznam ve fstabu vypadá jako NFS. Když chcete začít podporovat nový síťový souborový systém, musíte naučit mount ho rozpoznávat (to je asi ta slavná modularita – mount musí znát všechny možné síťové souborové systémy). Když je připojení souborového systému závislé na síti, možná to rozpozná mount. Když je připojení souborového systému závislé na přítomnosti nějakého zařízení, bude se to rozpoznávat jinak. Když je závislé na nějaké další službě, bude se to rozpoznávat ještě jinak. K čemu je to dobré? Není lepší, aby se o závislosti staral správce služeb, tak, jako to dělá u jiných služeb?

Možná, aby to někoho nedráždilo, se to mohlo oddělit na fstab a netfstab. Nebo si to dotyčný admin může dát do autofs. Ne, místo toho, bylo opět potřeba rozkopat něco, co fungovalo.
Ano, bylo možné přidávat další rovnáky na vohejbáky. A nebo to udělat znovu a pořádně, s přihlédnutím k dnešním potřebám a možnostem. Někomu, kdo se naučil vykličkovat s těmi rovnáky na vohejbáky, přesvědčil sebe a ostatní, že něco nejde, může vadit, že je to teď najednou přímočaré a jde to. Ale jinak nevidím výhodu v tom lepení různých workaroundů. Umožňují něco, co se systemd nejde udělat? Nebo v čem je problém?

Já nevidím jediný důvod, proč by se souborový systém na trvale připojeném lokálním zařízení měl připojovat nějak jinak, než souborový systém na dočasném nebo síťovém zařízení.

Ony se ve skutečnosti připojovaly stejně. Příkazem mount (a ne, opravdu nemusí hádat, co je to za fs, protože to má napsané ve fstabu. I ten nfs tam je.).

I tu slavnou flashku si uživatel mohl připojit, pokud byl v příslušné skupině a admin zadal příslušnou řádku do fstab s user.

nevšiml jsem si, že by to něco rozbilo

Já jo. Vám opravdu připadá koncepčně normální, že fs uvedený ve fstabu (takže se jaksi očekává, protože je to zavedené chování, že se má namountovat během bootu) se nepodaří namountovat a systém čeká (s unitou mount) na to, až se objeví device? Mimochodem, ten device poprvé (během bootu) selhal, protože se prostě mdadm odmítlo sestavit. Takže mu ta device unita selhala, potom se tam někdy (zásahem admina) objevila, takže se rozhodl pokračovat dál v unitě mount (která tam čekala dlouhé minuty od bootu). Tohle chování přinese mnoho krásných zážitků do nudného světa správy serverů.

A rada (kterou, jak se stalo již tradicí, opět nikdo z party sd-boys neuvedl), je upravit fstab a spustit systemctl daemon-reload (protože ten generator se spustí při early boot, takže na jakoukoliv úpravu fstabu během provozu OS kašle - tohle je koncepčně v pořádku?). To opravdu budeme při změně konfigurace bootu spouštět nějaký příkaz? Tohle má být správa OS roku 2016?

Není lepší, aby se o závislosti staral správce služeb, tak, jako to dělá u jiných služeb?

A ten správce služeb si ty závislosti na device a networku vycucá odkud? Bude to muset mít někde napsané úplně stejně, jako je to teď napsané ve fstabu. Takže jeden workaround, který se vám nelíbí, přejde na jiný workaround, který se vám líbí.

Připadá mi normální, že souborový systém, který má podle fstabu být přimountován, je přimountován v okamžiku, kdy je to možné. Naopak mi připadá nenormální, že souborový systém uvedený ve fstabu je nebo není přimountován podle toho, zda v určitém okamžiku při startu systému zrovna bylo nebo nebylo možné jej přimountovat.

To, že správce určí nějaká pravidla, v jakém stavu mají být které služby v závislosti na stavu systému, a správce služeb pak podle toho stav služeb udržuje, je v pořádku. Chybné (a přinášející mnoho krásných zážitků do nudného světa správy serverů) je naopak chování initů založených na SysVinit, které pouze nastartují systém do nějakého stavu, a dál už se o služby nestarají, nereagují na změny. Pak dochází k překvapením, protože systém po bootu je v unikátním stavu, ve kterém nikdy předtím nebyl. Admin se holt bude muset naučit, že změny nedělá dvakrát, jednou v běžícím systému a podruhé pro příští start, ale nastavuje to pouze jednou, a systemd se průběžně stará o to, aby služby byly v tom stavu, v jakém být podle administrátora mají.

generator se spustí při early boot, takže na jakoukoliv úpravu fstabu během provozu OS kašle - tohle je koncepčně v pořádku?
Není. Poslal jste patch?

To opravdu budeme při změně konfigurace bootu spouštět nějaký příkaz?
Pořád lepší spouštět nějaký příkaz a dostat systém do přesně definovaného stavu, než stav před systemd, kdy běžící systém změníte sadou nějakých příkazů, pak změníte konfiguraci bootu, a teprve při příštím bootu zjistíte, jestli jste ty změny udělal správně.

A ten správce služeb si ty závislosti na device a networku vycucá odkud? Bude to muset mít někde napsané úplně stejně, jako je to teď napsané ve fstabu. Takže jeden workaround, který se vám nelíbí, přejde na jiný workaround, který se vám líbí.
Já nepovažuju za problém to, že ty závislosti musí být někde uvedené. Problém je to, že ty závislosti řeší pokaždé někdo jiný a jiným způsobem.

Připadá mi normální, že souborový systém, který má podle fstabu být přimountován, je přimountován v okamžiku, kdy je to možné.

Ano, s tím se hrozně dobře pracuje. Například si vzpomínám na problém s NM, kde se okamžitě po změně konfigurace iface (managed, nebo co tam je, na no) a uložení souboru (nebylo potřeba ani reload) server odpojil od sítě, protože NM danou síťovku uvedl do stavu down (protože usoudil, že když se o ní nemá starat on, tak asi nikdo a není tak potřeba).

Takže IPMI a nastavit to znovu a lépe bez NM ...

Tohle všechno ukazuje na to, že autoři těchto nových řešení neviděli server ani na obrázku. Na tom se to totiž nejlépe pozná. Na papíře vypadá skvěle kde co. Zejména ti, co nemají žádné zkušenosti, skáčou radostí do stropu. Jenže potom se to nasadí v praxi, přijdou reálné situace, reálné chyby (jak hw, sw, tak i ty lidské) a teprve tam se ukáže, který systém je lepší.

Jestli se vám líbí způsob vývoje systemd, kdy Lennart boys nastaví nějaký limit (asi hádáním z kávové sedliny), v praxi se ukáže, že je to úplně mimo (což, kdyby jim alespoň někdo vyprávěl, co to ten server je, by věděli sami), takže to v další verzi zase změní na o něco vyšší vyvěštěné číslo, nebo to, že udělají změnu v zabíjení procesů při odhlášení a distribuce to potom mění (debian systemd 230-2) během kompilace a musí měnit conf default a man (což dodnes není hotové), tak jo. Užijte si ho.

Ano, pracuje se s tím dobře. Říkáte, v jakém má být systém stavu, ne jak do toho stavu dospět. Takže odpadají všechny ty problémy způsobené tím, že jste se do zdánlivě stejného stavu dostal různými cestami. To je důležité zejména pro servery – pracovní stanice se vypínají každou chvíli, to u serverů neplatí, takže tam je o to důležitější, aby server po restartu naběhl do stejného stavu, v jakém byl před restartem.

Akorát holt musíte změnit způsob práce a uvědomit si, že už neděláte ručně změny a vedle toho nekonfigurujete konfiguraci po bootu, ale pouze nakonfigurujete požadovaný stav systému, a init se postará o provedení změn.

Chápu, že po zkušenostech s předchozími inity je překvapivé, že správce služeb službu nastartuje, když se o ni má starat a služba má běžet, a zase ji vypne, když se o ni starat nemá, ale to je přesně to, co správce služeb dělat má. Když se starý správce služeb nastartuje, spustí služby, pak se správce ukončí a nechá po sobě v systému nepořádek v podobě běžících služeb, funguje špatně.

Takže odpadají všechny ty problémy způsobené tím, že jste se do zdánlivě stejného stavu dostal různými cestami.

Jasně, statická konfigurace sítě přinesla tuny problémů...

Místo toho se zavede managed networking, který je závislý na nějaké službě, která monitoruje stav souborů na disku (teď mě napadlo, co by se stalo, kdyby ten fs nebyl dostupný - vypnul by NM taky síť, aby se na ten server už pro jistotu nedalo přihlásit?).

Ale jo, je fajn svěřit síť službě, která přestane fungovat po přidání páté statické routy. To je moc fajn. ;-)

To, že za běhu konfiguruju síť příkazy ip a firewall příkazem iptables, ale po restartu se načte konfigurace z konfiguračních souborů, za problém považuju. Dotazů „nakonfiguroval jsem si firewall a po restartu mi to zmizelo“ už jsem pár viděl.

nakonfiguroval jsem si firewall a po restartu mi to zmizelo

Tak proč jim neřeknete (tak jako zde), že si to blbě nastavili? A třeba i vysvětlil rozdíl, mezi nízkoúrovňovým příkazem (který mohou použít ve skriptu na konfiguraci svého stroje) nastavující stav jádra a konfigurační službou?

To, že za běhu konfiguruju síť příkazy ip a firewall příkazem iptables, ale po restartu se načte konfigurace z konfiguračních souborů, za problém považuju.

Nic ti nebrani konfigurovat to skriptem.

Tvrdit o SysV initu, ve kterem se sluzby spousti serializovane, ze se do vysledneho stavu dostane ruznymi cestami mi prijde ponekud divne. Toto chovani bych spise ocekaval u initu jako je systemd, ve kterem se sluzby spousti paralelne, popr. jako akce na nejakou udalost. Toto nedeterministicke schovani na desktopu vicemene nevadi, ale na serveru mam rad, kdyz v pripade problemu vim, kde system skoncil, ktere sluzby nenajely a ze se logy take plni vicemene v ocekavanem poradi. Take si myslim, ze nezalezi na typu initu, jestlize sluzba behem startu systemu nenajede, kdyz je chyba v jeji konfiguraci. Tedy pozadovany stav muze byt jaky chcete, ale kdyz udelate chybu v konfiguraci, stejne ho nedosahnete.

Pokus o neco jako targety, zavislosti atd. ze systemd byl jiz v LSB, viz nasledujici hlavicka z init skriptu pro knotd (jestli to nekdy fungovalo, funguje [CentOS 5.x, 6.x], bohuzel nevim):

### BEGIN INIT INFO
# Provides: knot knotd
# Required-Start: $network $local_fs
# Required-Stop: $network $local_fs
# Should-Start:
# Should-Stop:
# Default-Start:
# Default-Stop:
# Short-Description: Knot DNS server daemon
# Description:
### END INIT INFO

Bohuzel v systemd chybi veci, na ktere byli admini pred tim zvykli, napr. jako vizualni potvrzeni akce - zda se povedla nebo ne. Systemd neco vypise pouze v pripade chyby, ale aspon ja jsem zvykly, ze kdyz startuji/stopu­ji/restartuji sluzbu, tak dostanu info OK nebo FAIL a nemusim se pro jistotu dotazovat na navratovy kod popr. status sluzby. V RedHati bugzille na toto exituje FR z roku 2013, ale zatim je to pry tezke implementovat.

Systemd spoustu veci pred adminem skryva, zamotava, zbytecne zobrazuje navic a nebo nezobrazuje vubec, dela uplne jinak a to je tezke; zde si myslim, ze mel byt vetsi duraz na kompabilitu ve stylu prace s jinymi inity. Na druhou stranu prinasi spoustu zajimavych myslenek, nastroju a reseni.

Napřed si stěžujete, že systemd se neaktualizuje automaticky, když změníte fstab

Možná si to přečtěte ještě jednou. Kdosi doporučoval, že by se měl editovat fstab, aby se zabránilo popsanému problému, tak jsem mu z manu vypsal řádek, že editovat fstab nestačí, ale je nutné reloadnout systemd. Rozhodně si nestěžuju, že systemd se nereloaduje automaticky, stěžuji si na to, že systemd cosi z fstabu vyrábí a navíc to pro jistotu ani neudržuje synchronní se svým stavem.

Kdy tohle systemd udělalo?

https://github.com/systemd/systemd/issues/2388

LP: I will bump the per-user limit to 16k now (from 4k), let's see how things work out with that.

Poettering změnil výchozí nastavení, aby se při testech našly všechny vadné programy, které se neregistrují do PAM a spoléhají na to, že PAM sessions se při ukončení neuklízí. A co jako?

Vadné? Proč vadné? Co přesně je vadného na tom, že proces udělá svůj fork a odpojí se od control terminálu?

Vadné? Proč vadné? Co přesně je vadného na tom, že proces udělá svůj fork a odpojí se od control terminálu?
Vadné je na tom to, že pak rodič nemůže ten proces řídit. To, že proces udělá svůj fork a odpojí se od control terminálu, aby byl z dosahu rodiče, akorát svědčí o „kvalitě“ předchozích init systémů.

pak rodič nemůže ten proces řídit.

No a?

akorát svědčí o „kvalitě“ předchozích init systémů

Už zase ta utkvělá představa. Já jsem o službě neřekl ani slovo.

Samozřejmě můžete mít v systému kupu volně ložených procesů, které možná běží a možná ne, možná zabírají nějaké systémové prostředky a možná ne, a nikoho to nezajímá.

Ale asi nemá smysl to dál řešit. Já preferuju automaticky spravované služby, protože je to deterministické, přenositelné, škáluje to. Vy preferujete ručně spravované služby, kdy si správce vše udělá ručně a žádný systém mu do toho nekecá. Já si myslím, že všechno směřuje k té automatizaci, protože je to ve výsledku spolehlivější a levnější, ale pro mne za mne, dělejte si to, jak chcete. Akorát pak systemd asi není zrovna vhodný nástroj, možná by to lépe řešil jediný skript, který spustíte při startu. Pokud už z nějakého důvodu musíte použít systemd, doporučuju používat simple nebo oneshot služby, které fungují přesně tak, že systemd něco spustí a dál už se o to nestará.

To vysvětluje mnohé... Jestli je provozování služeb, které zcela běžně padají a je třeba je zvedat deterministické, tak se asi snažíme s Linuxem zbytečně. Windows se tak chovají už roky a mají to dotažené k dokonalosti. A co to má společného se škálováním, to opravdu nevím.

A co to má společného se škálováním, to opravdu nevím.

Sluzby vam muzou padat paralelne, na tisicich nodu v clusteru.

Pravda, přesně po tom toužím od okamžiku, co jsem se rozhodl, že win partišna je zbytečná a o uvolněné místo jsem zvětšil tu linuxovou. Tak sláva, konečně si mi to splnilo.

Asi jsem ztratil kontext diskuse. Kde se tu vzaly padající služby?

[i]Samozřejmě můžete mít v systému kupu volně ložených procesů, které možná běží a možná ne, možná zabírají nějaké systémové prostředky a možná ne, a nikoho to nezajímá.

Ale asi nemá smysl to dál řešit. Já preferuju automaticky spravované služby, protože je to deterministické, přenositelné, škáluje to.[/i]

No to bych se měl ptát já, ne? Před systemd se prostě služba spustila a běžela, když jsem to initu řekl. Pokud padala, bylo něco špatně a bylo třeba to řešit. Za normálních okolností nepadala a pokud byla dobře napsaná a nastavená, poradila si i s takovou věcí, jako odpojená síť, nefunkční disky nebo pole a podobně. Pokud tak nefungovala, tak se opravila, nebo nahradila jinou, která tak fungovala, případně pokud selhalo něco kritického, tak se to muselo opravit tak jako tak. Řešit něco automatickým restartem bylo vždy něco výjimečného, nestandardního, zavrženíhodného a dříve nebo později na to většina správců dojela. Ale časy se mění, dnes není problém ani systemd hádající se s OOMK, protože se prostě něco pokazilo :D

OK, nevím, proč jste sem zavlekl padající služby a jestli to má nebo nemá nějak navazovat na předchozí diskusi, takže končím.

Ze stejného důvodu, z jakého sem byl zavlečen systém plný volně se povalujících služeb v neznámém stavu a podobných nesmyslů, které jsou mimochodem přes veškerou snahu o vymývání mozků spíše důsledkem systemd, než čehokoliv jiného.

Nejsem admin, ale opravdu nechapu, co nekterym administratorum na tomhle pristupu tak strasne vadi.

Jirsákovi se to zase bude strašně líbit, ale zdravé systémy prostě nepadají. Jako admin spravuju stovky serverů s tisícovkami služeb a služby, které se nastartují při bootu běží kontinuálně až do dalšího nařízeného rebootu (nebo třeba poweroff, máme hw servery, které se jednou zapnou, běží 6 let a potom se na konci své životnosti prostě vypnou - běží těch 6 let kontinuálně bez restartu).

Dá se to říct i naopak, služba, která se spoléhá na automatický restart, nemá na serveru co dělat.

Uptime služeb v jednotkách let není vůbec nic výjimečného.*

V takovem pripade je, z hlediska dostupnosti, zadouci, aby sluzba co nejdriv znovu nabehla, a nemuselo se cekat nekolik desitek minut nebo hodin nez ji administrator zrestartuje. Proc k tomu doslo se muze resit pozdeji.

Pokud je nějaká služba tak extrémně důležitá, tak stejně musí mít nepřetržitý dohled. Tedy admin je tam přítomný neustále.

Vysoká dostupnost se řeší úplně jinak, než neustálým restartováním bůh ví proč padající služby. Třeba tak, že danou službu převezme jiný server a ten vadný se odstaví.

*) Samozřejmě, můžeme se bavit o tom, jestli je to z hlediska bezpečnosti a updatů vhodné (rovnou říkám, že není a své servery si updatuji a rebootuji tak často, jak je potřeba), ale je to popis stavu.

Já s tím souhlasím, že zdravé systémy prostě nepadají. Akorát správce služeb nemá jak předem poznat, zda je daná služba zdravá. Navíc se tu pořád píše o tom, jak správce služeb nemá klást žádné nároky na spouštěnou službu – požadavek, že ta služba musí být absolutně zdravá, je extrémně silný a nesplnitelný.

Mimochodem, jeden ze základních způsobů, jak zajistit „zdravost“ nějakého komplexního systému, je počítat s tím, že jednotlivé komponenty toho systému mohou být nezdravé. Jakmile počítáte s tím, že vždy všechno perfektně funguje, sebemenší chybička vám celý systém složí.

Dá se to říct i naopak, služba, která se spoléhá na automatický restart, nemá na serveru co dělat.
Služba nemusí na automatický restart spoléhat. Automatický restart je způsob, jakým se správce služeb může vyrovnat s chybovým stavem, o kterém je dopředu známo, že může nastat.

U aut také můžete říci, že zdravá auta a zdraví řidiči prostě nebourají. A můžete to dokládat statistikou, kolik kilometrů už jste najezdil bez nehody. Přesto máte v autě bezpečnostní pásy, airbagy a deformační zóny – protože u auta je vám jasné, že i když výrobce chce udělat bezchybné auto a vy chcete bezchybně řídit, ještě to neznamená, že k havárii nedojde.

Vysoká dostupnost se řeší úplně jinak, než neustálým restartováním bůh ví proč padající služby. Třeba tak, že danou službu převezme jiný server a ten vadný se odstaví.
Ano, vysoká dostupnost se neřeší konstatováním „zdravé systémy prostě nepadají“, vysoká dostupnost se řeší tak, že se s možným pádem služby předem počítá a vytvoří se automatizovaný postup, který v případě pádu služby nějak zajistí její další dostupnost. Přičemž shodou okolností systemd zrovna tohle umožňuje udělat a počítá s tím.

U aut také můžete říci, že zdravá auta a zdraví řidiči prostě nebourají. A můžete to dokládat statistikou, kolik kilometrů už jste najezdil bez nehody. Přesto máte v autě bezpečnostní pásy, airbagy a deformační zóny – protože u auta je vám jasné, že i když výrobce chce udělat bezchybné auto a vy chcete bezchybně řídit, ještě to neznamená, že k havárii nedojde.

Ano, u auta jsou bezpečnostní prvky pro minimalizaci následků havárie. Určitě tam nejsou proto, aby havarovaný vůz okamžitě řidič nastartoval a jel dál. Havarované auto posuzuje odborník, a řidiče, zejména viníka nehody, posuzují příslušné orgány, jestli a kdy mu dají právo řídit.

Stejně tak, pokud zhavaruje služba, je na odborníkovi, aby posoudil, proč k tomu došlo. Je dobré, to dostat do nějakého bezpečného stavu, například ji vypnout; odstavit od dat a zabránit tak jejich případnému poškození.

Pokud je daná služba kritická pro nějakou infrastrukturu, tak musí být zajištěna její redundance, například tím, že bude poskytována jinou implementací (viz třeba kořenové servery).

Automatizace je sice hezká věc, ale opakovaně se ukazuje, že je to extrémně drahé a extrémně náročné udělat dobře. Blbě udělaný automatický systém udělá víc škody jak užitku. (A nemám důvěru v automat od autorů, kteří ani nevědí, jakou veličinu nastavují a její hodnotu zkouší stylem pokus omyl.)

Ano, u auta jsou bezpečnostní prvky pro minimalizaci následků havárie.
Přesně tak. A pokud je ukončení procesu považováno za havárii, což často je, musí také správce služeb poskytovat nějaký způsob, jak na takovou havárii, tedy ukončení procesu, reagovat.

Stejně tak, pokud zhavaruje služba, je na odborníkovi, aby posoudil, proč k tomu došlo. Je dobré, to dostat do nějakého bezpečného stavu, například ji vypnout; odstavit od dat a zabránit tak jejich případnému poškození.
Což ovšem nijak nesouvisí s procesem té služby, protože služba může havarovat aniž by se proces ukončil, stejně jako může být služba v havarovaném stavu a neběžet, aniž by před tím došlo k ukončení procesu (např. pokud mezi havárií služby a aktuálním okamžikem došlo k restartu počítače). Zkrátka to, v jakém je služba stavu, musí umět posoudit ona sama. Ostatně, myslím, že s tím sám máte jistou zkušenost – přestože nedošlo k pádu žádného procesu, měl jste havarovanou službu (rozpadlý RAID), a ta služba nebyla nakonfigurovaná, aby na havárii reagovala správně.

Automatizace je sice hezká věc, ale opakovaně se ukazuje, že je to extrémně drahé a extrémně náročné udělat dobře.
To sice ano, ale ještě dražší a náchylnější k chybám je dělat to ručně. Google nebo Amazon neautomatizují své procesy proto, že by to bylo dražší a poruchovější. Ostatně celý princip cloudu byl umožněn právě tím, že se správa služeb automatizovala.

A pokud je ukončení procesu považováno za havárii, což často je, musí také správce služeb poskytovat nějaký způsob, jak na takovou havárii, tedy ukončení procesu, reagovat.

Opět připomínám, bavíme se o restart on failure. Asi každý admin zná nějaký cluster ware, který při chybě služby umí reagovat tak, že to pustí na vedlejším nodu. Což je taky reakce. O tom ale diskuse nebyla.

protože služba může havarovat aniž by se proces ukončil, stejně jako může být služba v havarovaném stavu a neběžet

No samozřejmě, to se tady ale několikrát J snažil vysvětlit, že stav služby jen těžko může posuzovat správce (typu systemd), protože k tomu nemá žádné prostředky. Systemd tak maximálně ví, jestli běží nebo neběží nějaký proces, ale nemá páru o tom "jak dobře to běží". Takže v případě, kdy se služba zasekne v nekonečné smyčce, proces běží samozřejmě dál a systemd je happy a služba nefunguje.

Google nebo Amazon neautomatizují své procesy proto, že by to bylo dražší a poruchovější.

Přesně, a vůbec nikdy se nestalo, že vypadlo celé jedno pobřeží. ;-)

Tohle ukazuje na módy chyb. Zatímco pokud se admin uklepne u ruční práce, tak ohrozí maximálně tak jeden server, tak u automatizace se rovnou ohrožuje celá serverovna (aneb známé případy, kdy "devops" zhodil stovky služeb současně).

Jsou také moc hezké případy rozpadu energetické sítě, kdy automatické prvky zareagovaly tak, že příslušné přetížené větve vypnuly. Hezky kaskádně to popadalo. Kdyby tam byl člověk znalý, tak třeba uzná, že 150% přetížení ty prvky i pár hodin snesou (protože třeba ví, kdy bude opravená jiná větev - třeba za pár desítek minut) a je to lepší stav, než když to přejde do ostrovního režimu, kam to krásně poslala ta automatika a potom se to ručně skládalo dva dny.

Když potřebuji vysokou dostupnost, tak je to jednoduché. Po pádu služby ji přebere jiný node a ten, na kterém to spadlo, tu službu nikdy nemůže vzít zpátky, dokud to admin neprozkoumá a neodblokuje. Je to zajímavé, ale z opravdu kritických služeb na serverech, o které se starám, jsem nikdy neviděl žádnou, která by spadla jen tak bezdůvodně.

Poettering změnil výchozí nastavení, aby se při testech našly všechny vadné programy, které se neregistrují do PAM a spoléhají na to, že PAM sessions se při ukončení neuklízí.

Joj, to je ale uzasna metoda. To je jako shodit sarin na vesnici a pak to tam jit za 14 dni ocuchat a podle smradu zjistit, jestli byla obyvana. Ono by samozrejme nebylo mozne napsat neco, jako popularity contest v debianu, ktery by byl pri upgradu dobrovolne aktivovany adminem a posilal by informace o chovani aplikaci. Ne, ono je lepsi vsechno rozbit a dat lidem nuz na krk. Bud prejdou na viru systemd nebo budou o hlavu kratsi. Mezitim at si useri trhnou nohou.

"Admin se holt bude muset naučit, že změny nedělá dvakrát, jednou v běžícím systému a podruhé pro příští start, ale nastavuje to pouze jednou, a systemd se průběžně stará o to, aby služby byly v tom stavu, v jakém být podle administrátora mají."

Rekl bych, ze toto plati jak pro SysV init, tak i pro systemd. V obou initech muzu nastavit spousteni sluzby behem startu, ale zaroven ji nemusim spustit a nebo opacne, muzu sluzbu spustit, ale uz ji nemusim nastavit pro start behem bootu OS. Ano systemd na to ma zkratku pomoci parametru --now, ktery obe akce (enable+start a disable+stop) provede najednou, ale toto nekazdy bude znat. Tedy pokud si chci byt jisty, ze mi system najede, tak jak ja chci, tak kontrolni restart zustava nutnosti.

Dle meho nazoru systemd prinasi jen dalsi komplikace s mechanizmem socketu, pekna myslenka, ale pro testovani, ze vse funguje tak jak ma, je to dalsi krok navic. Se SysV initem treba pro rychlou kontrolu stacilo vylistovat procesy a mrknout, co za procesy na serveru bezi a ktere ne. V pripade aktivace pres sockety, musim nejdrive pristopit na dany socket, aby se sluzba "mozna" spustila (bohuzel ne vsechny aplikace umi kontrolu konfigurace mimo start sluzby).

Pan Jirsáku, to, že se někomu nelíbí systemd neznamená že je jenom obyčejný hater a nula co ničemu nerozumí. Taková argumentace akorát ukazuje
Já jsem takovou argumentaci nepoužil. Já jsem napsal, že většina odpůrců systemd jsou jen systemd-haters, a většina nejsou všichni.

tak už se to sere i do fs
Není pravda.

Místo aby služby sjednotil, tak je nahrazuje
Co to znamená, že by měl služby sjednotit? Systemd nenahrazuje služby jen tak z plezíru, ale vytváří takové služby, které jsou pro infrastrukturu systemd potřeba. Systemd řídí stav služeb na základě událostí, ke kterým v systému dochází. Může plynutí čau generovat nějaké události v systému? Nepochybně ano. Takže dává smysl umožnit měnit stav služeb i na základě plynutí času - buď v intervalu od nějaké jiné události, nebo v pravidelném intervalu. A že tnehle mechanismus vlastně může nahradit cron? No ano, může - a vadí to něčemu?

rozbíjí kompatibilitu se vším co potká
Když je někde nepořádek, nejde to vyčistit tak, že zachováte zpětnou kompatibilitu a budete i po úklidu pořád vypadat, že je tam nepořádek.

úplně stejně debilně zní to Vaše "že většina odpůrců systemd jsou jen systemd-haters, a většina nejsou všichni."
Jenže já jsem nepsal, že většina odpůrců jsou jen systemd-haters proto, že nemají rádi systemd. Odkazoval jsem na komentáře v této diskusi. Pokud chcete konkrétní příklad - to, že si někdo vymyslí lež o tom, jak systemd znemožní fungování cronu, není příklad bryskního uvažování a nadprůměrného vzdělání. Je to naopak příklad toho, že dotyčný prostě nenávidí systemd, musí to nějak dát najevo a je mu úplně jedno, jestli to, co píše, je pravda, lež nebo nesmysl. A takových komentářů od odpůrců systemd je v této diskusi i v ostatních většina.

když je to tak potřeba všechno přepsat?
Není potřeba všechno přepsat. Tvrdil to snad někdo? Nasvědčuje tomu něco? Proč jste tedy něco takového napsal, když jste si musel být vědom toho, že to není pravda? To je důkaz vašeho vzdělání, scestovalosti a rozhledu nad životem, že píšete věci, o kterých musíte vědět, že nejsou pravda?

Jako pardon, ale kdyby to tak nedojebávalo ostatní věci, tak bych to fakt uvítal.
Já bych nejdřív uvítal aspoň jeden příklad té rozbité ostatní věci. Většina příkladů, které jsem zatím někde viděl popsaných, spočívala v tom, že měl někdo něco špatně nastavené, jenže spolu s polofunkčním initem to ve výsledku dělalo to, co si dotyčný představoval. A když teď dotyčný dostal do ruky funkční systemd, neví, co si má počít s tím svým špatným nastavením. Je to úplně stejné, jako když jiní v diskusích o IPv6 vysvětlují, jaký je to nesmysl, protože bez NATu nemůže žádná síť fungovat.

dokázala spolupracovat s ostatníma a to co dělají nechat na nich.
To systemd dělá. Jenže když úlohou nějaké komponenty je poslepovat k sobě několik různých hacků, není řešením napsat emulaci těch hacků, ale napsat ty komponenty tak, aby se bez těch hacků obešly.

No to si pište že jde. Už jsem Vám to psal minule. Je to stejné, jako když měníte třeba databázi na produkci za pochodu - prostě se akorát nevys....na ostatní závislosti . . . Prostě se implementuje nová a zachová stará. Nic na tom není. Jen trocha myšlení a práce.
Nejde. Za pochodu můžete dělat úpravy nebo něco vylepšovat. Nemůžete za pochodu odstranit hacky tak, aby tam pořád zůstaly. Když něco "uklidíte" tak, aby to vypadalo, že je tam pořád nepořádek, bude tam pořád nepořádek. Prostředí založené na SysVinitu je soustava hacků, ty hacky tvoří to podstatné. Když hacky odstraníte, zbydou vám akorát ty komponenty, ale ten původní základ je pryč a musíte jej nahradit něčím novým.

Zkuste si natankovat do nového auta Natural 91. Nebo olovnatý benzín.

Tak ono je to naopak. Do starych aut se tankuje bezolovnaty benzin. Byl udelan tak, aby pasoval na starou technologii aut. Systemd jde na to tak, ze novou technoligii rve do stare tak, aby to vyvolalo co nejvice problemu na vsech stranach. Tak nejak, jako kdyby bezolovnaty benzin znicil na starem aute funkci steracu a pri pokusu o zamceni dveri pri jihozapadnim vetru by ty dvere upadly.

Tak ono zalezi na tom, o jak starem aute mluvime. Moje pochazi z doby pred bezolovnatymi benziny a zadne sracky se do nej pridavat nemusi, jede na normalni benzin 95 oktanu. Pokud mluvis o veteranech z prvni svetove valky, tak zalezi na kompresnim pomeru. Ty ale asi tezko mel nekdo na mysli, kdyz se zavadel bezolovnaty benzin.

Tak to jo, ta ma motor nekdy z doby druhe svetove valky.

Ale to víte že to jde. I se to tak dělá. To je pak tím, že když si koupíte nové auto, tak pořád můžete tankovat i na staré pumpě, když si koupíte nový komp, tak do USB3 dáte i USB2, na kompech jsou pořád VGA i když už dnes frčí hdmi, kvůli šetrným spotřebičům nikdo nemění ve všech bitech v republice zásuvky
Vy pořád nechápete, v čem je ten rozdíl. Vy popisujete příklad, když máte nějakou vlastnost, a tu samou vlastnost implementujete jiným způsobem. Ano, když máte auto na benzín, a pořídíte si jiné auto na benzín, můžete tankovat pořád benzín. Já píšu o systemd, které se snaží opravit některé špatné vlastnosti předchozích správců služeb. Takže máte nějakou vlastnost, která je špatná, a nahradíte ji jinou vlastností. Když se vám bude zdát, že benzín je příliš drahý a koupíte auto na plyn, nemůžete do něj dál tankovat benzín. Když si pořídíte auto na plyn, které bude zpětně kompatibilní a půjde do něj tankovat benzín, a vy do něj budete tankovat benzín, jaksi jste přišel o tu vlastnost, proč jste si auto na plyn kupoval, a dál jezdíte na drahý benzín. Nejde udělat auto, do kterého budete tankovat benzín, ale platit budete levný plyn.

Třeba to co popisuje zde pan Heron, ať nechodíme daleko.
To není příklad toho, že by něco systemd rozbilo. To je příklad chybné konfigurace.

Ono to spíš znamená, že si bude muset zvyknout, že když něco nastaví jak má jet, tak systemd si to ještě přehodnotí a spustí si co uzná za vhodné.
Neznamená, to je opět váš blud. Jak jste na takový nesmysl přišel? Máte nějaký příklad, kdy by systemd spouštěl něco jiného, než co má v konfiguraci?

při rebootu po 2 měsících to může být zase jinak, protože chování někdo změnil v patchi
Nemůže, protože když aktualizujete systemd, zrestartujete i systemd a to nové chování se vám projeví hned. Že se změnilo chování se dozvíte z release notes.

otestuji restartem
Otestuji restartem? To jsme ve Windows, nebo co? Normální správce služeb se chová tak, že udržuje služby ve stavu odpovídajícím stavu systému. Bez ohledu na to, jestli mezi tím restartujete počítač.

To vaše "otestuji restartem" nebo "rebootuju, aby se aktualizoval systemd" jsou právě příklady toho, kdy to děláte špatně (protože to dříve jinak nešlo), a teď to špatné chování požadujete i po novém systému. Přesně jako ti správci, kterým bez NATu nemůže fungovat IPv6 síť.

To není příklad toho, že by něco systemd rozbilo. To je příklad chybné konfigurace.

Ne, to je příklad toho, že systemd změnilo roky zavedenou věc. Ale předpokládám, že se dozvím - on už to tu dokonce i někdo napsal - že je to moje chyba, protože si mám přečíst man - pokud teda zrovna bude aktuální.

Hele, mě by vlastně vůbec nevadilo, kdyby systemd ohlásil, že od verze 400 se nebude fstab používat. Klidně bych si to do těch unit přepsal už teď, tak jak jsem to udělal u dalších komponent, a fstab bych smazal. (Jak jsem psal na blogu, ten formát se mi docela líbí.) Ale co mi vadí je, že se náhle změní desítky let zavedený koncept, systém se začne chovat zcela jinak a borci na fóru to označí za chybu konfigurace. Pokud je v tom fstabu něco špatně, tak na to má ten generátor upozornit. (Samozřejmě, že není. Není to chyba konfigurace, je to plíživá změna konceptu.)

Že se změnilo chování se dozvíte z release notes.

Jasně, teď si dáme minutu předstírání, že všichni čtou každý release notes a zejména u věcí, které jsou desítky let staré. (Když už to tady sklouzlo k autům, tak přece nikoho nemůže překvapit, že se plyn přidává pákou, která dodnes sloužila jako ruční brzda, protože je to přece napsáno v manuálu.)

Ne, to je příklad toho, že systemd změnilo roky zavedenou věc.
Ano, za ta desetiletí, co se bastlilo se SysVinitem, je zavedená spousta nesmyslů. Když se těch nesmyslů chcete zbavit, musíte měnit zavedené věci. Jak už jsem několikrát psal, pro některé administrátory je nasazení IPv6 problém, protože mění roky zavedenou věc – NAT. Jenže když NAT škodí a s IPV6 není potřeba, je přece nesmysl ho do IPv6 sítě cpát jenom kvůli tomu, že je to roky zavedené.

Klidně bych si to do těch unit přepsal už teď, tak jak jsem to udělal u dalších komponent, a fstab bych smazal.
To by bylo řevu v diskusích. Jak systemd všechno rozbíjí, není zpětně kompatibilní, jak bez fstabu nemůže nic fungovat, jak systemd pohlcuje souborové systémy…

Ale co mi vadí je, že se náhle změní desítky let zavedený koncept, systém se začne chovat zcela jinak a borci na fóru to označí za chybu konfigurace.
Ten desítky let zavedený koncept byl, že tu máme jakýsi zárodek správce služeb, který služby při startu počítače nějak nastartuje, a pak už se o nic nestará. Koncept systemd je, že tu máme správce služeb, který se o služby stará trvale a udržuje je ve stavu, v jakém podle konfigurace a stavu systému mají být. To není žádná náhlá změna v průběhu vývoje systemd, to je koncept jasný už od okamžiku vzniku systemd (a některé inity ho používaly už před systemd, dokonce i SysVinit tohle uměl). K tomu nemusíte číst žádné manuály nebo release notes, to je princip, který funguje v systemd od začátku.

Takže stačí se tak k systému chovat, nepočítat s tím, že init je rozbitý a neumí na změny v systému reagovat, ale naučit se postupovat tak, že když nějakou službu chci dočasně vypnout, musím ji opravdu nastavit do vypnutého stavu.

Ten váš příklad s rozbitým RAIDem je opravdu příklad chybné konfigurace, která se akorát shodou náhod a chyb starého initu dříve neprojevila. Chyba byla především v tom, že se na rozbitý RAID pouští fsck se zápisem na disk. Že se to nespustilo nikdy dřív bylo dané chybným chováním starého initu, který neuměl detekovat připojené zařízení a přimountovat ho (přičemž to samé by mohl dělat třeba udev, a také to není chyba udevu). A zároveň to bylo věcí náhody – kdyby se starým initem něco způsobilo restart počítače s tím vadným polem, při startu by se ho init pokusil připojit a dopadlo by to úplně stejně.

Ano, desítky let zavedené postupy spoléhající na to, že init je rozbitý, opravdu se systemd nefungují, ale to je záměr. Záměrem nebylo napsat další rozbitý init, záměrem bylo napsat init, který bude (alespoň v rámci dnešních znalostí a možností) fungovat správně.

Ano, za ta desetiletí, co se bastlilo se SysVinitem, je zavedená spousta nesmyslů. Když se těch nesmyslů chcete zbavit, musíte měnit zavedené věci.

Mě se líbí, jak se tady vrší spousta invektiv. Nemáme se systemd bát; bastlilo; workardoundy; rovnáky na vohejbáky; nesmysly apod. :-D

Nejlepší způsob, jak se zbavit nesmyslů, je přijít se zcela novým řešením a na to prostě přejít. Ne postupně rozbíjet vše existující. U některých komponent to systemd evidentně umí a je jen na adminovi, zda je použije (já je používám).

Když už je zde analogie se sítí, tak správným řešením problému ifconfig (na linuxu) mělo být zavední ip(route2) (to se povedlo), a včasné dropnutí podpory ifconfig (to se nepovedlo).

Jenže když NAT škodí a s IPV6 není potřeba, je přece nesmysl ho do IPv6 sítě cpát jenom kvůli tomu, že je to roky zavedené.

Souhlasím. Ať systemd nechá fstab být a místo toho zavede filesystemd a nechť ohlásí ve verzi 400 dropnutí podpory fstabu. IPv6 také žádný způsobem neničí NAT na IPv4. Ty věci mohou paralelně fungovat vedle sebe. (U toho dualstacku je to jednodušší, u fstab by se muselo zajistit, aby si vzájemně nelezly do zelí.)

To by bylo řevu v diskusích. Jak systemd všechno rozbíjí, není zpětně kompatibilní, jak bez fstabu nemůže nic fungovat, jak systemd pohlcuje souborové systémy…

Takže se téhož dosáhne salámovou metodou a postupným rozbíjením různých dosud funkčních komponent.

Chyba byla především v tom, že se na rozbitý RAID pouští fsck se zápisem na disk.

Když si všimnete, tak zrovna toto nekritizuju. To, že fsck volaný z initu by default dělá "bezpečné" opravy, vím. Kritizuju stav, že když se nepodaří nastartovat nějakou device při early bootu, tak mount service si v klidu a pohodě čeká na to, až se tam to device jednou objeví. To, že device je failed asi znamená, že je něco špatně, takže by se měly všechny ostatní závislosti zrušit a ne se to tam pokoušet narvat, jakmile je zpět online.

Že se to nespustilo nikdy dřív bylo dané chybným chováním starého initu, který neuměl detekovat připojené zařízení a přimountovat ho (přičemž to samé by mohl dělat třeba udev, a také to není chyba udevu).

Mě se líbí, jak všude vnucujete tu svoji utkvělou představu o tom, jak by se měl, podle vás, systém chovat, a jakékoliv jiné chování označujete za chybu.

Nebojte se. To, že máte rád všechno managed tu asi pochopil každý.

A zároveň to bylo věcí náhody – kdyby se starým initem něco způsobilo restart počítače s tím vadným polem, při startu by se ho init pokusil připojit a dopadlo by to úplně stejně.

Ne, nedopadlo, protože to pole by se automaticky nesestavilo. Takže i kdyby se něco rebootovalo, tak by tam ten block device opět nebyl. Kdyby se to jen tak z plezíru natvrdo rebootovalo, tak by to byla známka většího poškození hw.

Mě se líbí, jak se tady vrší spousta invektiv. Nemáme se systemd bát; bastlilo; workardoundy; rovnáky na vohejbáky; nesmysly apod. :-D
To nejsou nesmysly, to je konstatování faktu. To, že se mount zabývá sítí, není rozumné chování. To, že se proces vzdá výstupu na standardní výstup a odforkuje se z dosahu rodičovského procesu, to nevypovídá o kvalitě init systému. To, že se systém chová jinak po startu počítače a jinak za běhu, není žádná super vlastnost.

Nejlepší způsob, jak se zbavit nesmyslů, je přijít se zcela novým řešením a na to prostě přejít.
A co jiného dělá systemd? Nové řešení samozřejmě rozbije ty věci, které mění. To není záměr, to je důsledek.

Když už je zde analogie se sítí, tak správným řešením problému ifconfig (na linuxu) mělo být zavední ip(route2) (to se povedlo), a včasné dropnutí podpory ifconfig (to se nepovedlo).
To je trochu problém. Systemd je na jednu stranu vytýkáno, že věci mění příliš rychle, že by všechno mělo být zpětně kompatibilní a že nereflektuje skutečné potřeby uživatelů a správců. A vy na druhou stranu systemd vytýkáte, že má udělat všechny změny najednou, že se mělo připravit někde v tajnosti bokem a pak všechno naráz předělat. Jak chcete vyhovět oběma stranám?

Kritizuju stav, že když se nepodaří nastartovat nějakou device při early bootu, tak mount service si v klidu a pohodě čeká na to, až se tam to device jednou objeví.
To je správné chování. Špatné chování je naopak to, když připojení závisí na tom, jestli se zařízení objeví v systému před nebo po nějakém náhodném okamžiku po bootu systému.

To, že device je failed asi znamená, že je něco špatně, takže by se měly všechny ostatní závislosti zrušit a ne se to tam pokoušet narvat, jakmile je zpět online.
To, že je device failed, znamená, že je něco špatně a že se nemá připojovat. Když není failed a má nastaveno, že se má připojovat, je správně, že se připojí. Když není failed a přesto se nemá připojovat, musí to administrátor systému nakonfigurovat. Špatně je to, když stav připojení závisí na tom, že zařízení někdy bylo failed a systém si to od té doby náhodou ještě pamatuje.

Mě se líbí, jak všude vnucujete tu svoji utkvělou představu o tom, jak by se měl, podle vás, systém chovat, a jakékoliv jiné chování označujete za chybu.
Jenže ona to chyba je. Pokud má systém fungovat podle vaší představy, tedy po bootu proběhne nějaká série operací, a po jejich dokončení už veškeré operace musí provést ručně administrátor, nepotřebujete vůbec žádné init skripty. Prostě si napište shell skript, který potřebné operace provede a který spustíte po bootu, a máte vystaráno.

Samozřejmě nikdo nemusí používat správce služeb. Ale když už používá správce služeb, měl by ten správce fungovat – správce služeb, který služby spravuje někdy a tak trochu, funguje špatně.

Kdyby se to jen tak z plezíru natvrdo rebootovalo, tak by to byla známka většího poškození hw.
Nebo třeba známka ztráty napájení.

To, že se mount zabývá sítí, není rozumné chování.

Mount se zabývá sítí pouze do té míry, že připojuje síťové fs. Pokud není síť dostupná, tak ohlásí chybu. Co je na tom špatně?

To, že se proces vzdá výstupu na standardní výstup a odforkuje se z dosahu rodičovského procesu, to nevypovídá o kvalitě init systému.

Opakuji podruhé, nemluvil jsem o initu. Vy jste v životě nepoužil nohup? V životě jste nespustil program -d na příkazové řádce? V životě jste nepoužil tmux? Co je konkrétně špatně na tom, když se proces odpojí od control terminálu?

A vy na druhou stranu systemd vytýkáte, že má udělat všechny změny najednou, že se mělo připravit někde v tajnosti bokem a pak všechno naráz předělat.

Nic takového jsem netvrdil. Můžete používat ntp, nebo si můžete nastavit timesyncd. Můžete používat resolved, nebo taky nemusíte. Můžete používat networkd nebo taky nemusíte. Můžete si nastavit timery, nebo taky nemusíte. Žádné toto řešení neničí stávající existující služby a je pouze na adminovi, které řešení si vybere. Takže to není žádné najednou a v tajnosti. Prostě nechť si systemd implementuje vše, co uzná za vhodné a nechť je na adminovi, kdy přejde (a klidně to může při bootu hlásit, že ve verzi 400 už nebude podporováno původní řešení). Já jsem ve všech výše zmíněných případech přešel dobrovolně na systemd, ale stále mohu používat jiné implementace daných služeb (například stále mám v systému crond, ale jako user už používám .timer).

Nebo třeba známka ztráty napájení.

Nebo na to může spadnout meteorit.

Tak já to shrnu, ju? Správce služeb má služby spravovat, ne nahrazovat, když se mu náhodou něco nehodí, ne je nutit, aby byly na konkrétním správci závislé.

Má je prostě spustit ve správném pořadí, může je i hlídat a dle nastavení provádět různé akce při jejich selhání. Potud v pořádku, nemám problém a je mi úplně jedno, jestli to udělá jeden skript, nebo sada skriptů, jestli se to jmenuje SysV, nebo OpenRC, nebo třeba systemd. Ale tím končí úloha initu/správce služeb.

V okamžiku, kdy toho začne dělat víc, tak to má být samostatná služba, kterou nemusím používat, která mě do ničeho nenutí a kterou kdykoliv nahradím jinou službou, která mi bude víc vyhovovat.

To, že init uvede něco do zcela neurčitého stavu, jak tu zaznělo, to se dříve stávalo, pokud byl nějaký problém a tak jako tak bylo třeba jej vyřešit. Toto chování kupodivu poslední dobou způsobuje spíše systemd, než cokoliv jiného.

A ta neskutečná arogance, požadovat po někom, aby upravil svůj SW tak prasácky, aby se systemd fungoval, to je ten největší narovnák na vohejbák na na natahováku na zkracováku.

A to, že tenhle celej nesmysl navíc komplikuje portování aplikací mezi různými OS, to už je jen taková třešnička na dortu.

Jestli nakonec padne Gentoo a bez systemd to nepůjde, tak odcházím k *BSD a vypadá to, že takových bude víc.

Tak já to shrnu, ju? Správce služeb má služby spravovat, ne nahrazovat, když se mu náhodou něco nehodí, ne je nutit, aby byly na konkrétním správci závislé.
Tohle systemd perfektně splňuje.

Má je prostě spustit ve správném pořadí, může je i hlídat a dle nastavení provádět různé akce při jejich selhání.
Kdyby to mělo jenom spouštět služby, pak je to spouštěč služeb, ne správce služeb. Správce služeb má služby spravovat po celou dobu běhu systému, tzn. má reagovat na změny v systému a na jejich základě měnit stav služeb. Správce sítě také nemáte jenom od toho, aby vám síť jednou na začátku nakonfiguroval a pak už se o ní nestaral, ale chcete po něm, aby síť průběžně udržoval, opravoval a také přizpůsoboval změnám. To samé správce počítače – to není někdo, kdo počítač nainstaluje a předá vám ho, ale někdo, kdo se o něj stará po celou dobu životnosti počítače.

V okamžiku, kdy toho začne dělat víc, tak to má být samostatná služba, kterou nemusím používat, která mě do ničeho nenutí a kterou kdykoliv nahradím jinou službou, která mi bude víc vyhovovat.
systemd toho víc nedělá. Existují samostatné služby vyvíjené v rámci projektu systemd, obvykle pojmenované systemd-*. Ty ovšem nejsou součástí správce služeb, jsou to přesně ty samostatné služby, které nemusíte používat a kdykoli je můžete nahradit.

To, že init uvede něco do zcela neurčitého stavu, jak tu zaznělo, to se dříve stávalo, pokud byl nějaký problém a tak jako tak bylo třeba jej vyřešit.
Ne, to se nestávalo jen dříve a jen v případě, že je nějaký problém. Když třeba připojíte flash disk, skončí systém ve dvou různých stavech v závislosti na tom, jestli jste flash disk připojil před nebo po okamžiku mountování souborových systémů. To samé, když připojíte síťový kabel.

Toto chování kupodivu poslední dobou způsobuje spíše systemd, než cokoliv jiného.
Například?

A ta neskutečná arogance, požadovat po někom, aby upravil svůj SW tak prasácky, aby se systemd fungoval, to je ten největší narovnák na vohejbák na na natahováku na zkracováku.
Kdy to kdo po někom požadoval?

A to, že tenhle celej nesmysl navíc komplikuje portování aplikací mezi různými OS, to už je jen taková třešnička na dortu.
Jak systemd komplikuje portování mezi různými OS?

Jestli nakonec padne Gentoo a bez systemd to nepůjde, tak odcházím k *BSD a vypadá to, že takových bude víc.
No jo, vyhrožování v diskusích, že odejdete, to vám jde. Akorát jste zapomněl na jednu věc – aby vyhrožování odchodem bylo účinné, musel by váš odchod někomu vadit. Nebo spoléháte na to, že uživatelé *BSD se chopí vývoje systemd, protože se zděsí, že k nim jinak přitáhne partička uživatelů, která jim začne vysvětlovat, jak to dělají blbě a měli by to dělat úplně jinak, a oč méně budou mít skutečných argumentů, o to více si jich prostě vymyslí?

Kdy to kdo po někom požadoval?

Krátká paměť?

https://github.com/tmux/tmux/issues/428

Ne. Akorát tohle není „požadovat po někom, aby upravil svůj SW tak prasácky“.

Tak třeba systemd nahradil logování zabugovaným binárním krámem, který nefunguje ani přes různé verze a nedá se vypnout. Dá se sice log přeposlat dál, ale když se ta systémd ptákovina sesype, přeposílání se sesype s ní. Takže nejen že nahradil, ale velmi omezuje i použití něčeho jiného.

Do toho, kdy si co strčím do kterýho portu, do toho initu nic není. Buď v dané situaci může spustit závislosti, nebo nemůže. Na síť i na úložiště doteď fungují jiné samostatné služby, které se na to specializují a že se mi něco spustí automaticky po nějakém chybovém stavu, který skončil, to osobně nepovažuji za žádoucí stav. Pokud se mi například přehřívá switch a restartuje se, opravdu nechci, aby se mi služba sama nahazovala a shazovala. Já vím, automaticky je to pohodlné, ale já pracuji v prostředí, kde se každá chyba zkoumá a zjišťuje se, jak jí do budoucna předejít a hlavně se po každé chybě zjišťuje, co dalšího se mohlo pokazit. V tom mi automaticky restartující se služba opravdu nepomůže a nadělá víc škody, jak užitku. V tomto kontextu jsem vlastně zcela proti univerzálnímu správci služeb, co spravovat chci, většinou na desktopu, to má svoje funkční a dostatečně prověření řešení už nyní a zbytek je jen maskování chyb.

Nevysvětlitelné chování systemd způsobuje například dodrbaný log, což bohužel není situace zase tak moc výjimečná, ale dalo by se pokračovat, třeba jsem měl v ruce tři identické notebooky s naklonovanou instalací RH a i když nebyl žádný z nich v okamžiku bootu připojený k síti, zcela náhodně kterýkoliv z nich na tu síť čekal v intervalu půl minuty až několik minut, možná i do nekonečna, kdybych na to měl tolik času.

Jak už někdo řekl, krátká paměť. Požadovat po někom, aby si přidal závislosti proto, že jsem mu právě rozbil roky fungující aplikaci, je prostě neskutečná arogance a prasárna hodná MS. Vzhledem k tomu, že to páni Lenártovci evidentně věděli, že něco rozdrbou, tak bych považoval za slušnost s implementací podobných nesmyslů počkat a na téma kde je chyba vyvolat diskuzi. Zprasit to a pak kopat kolem sebe, jak jsou všichni blbci a dělají to špatně, to je opravdu nejvhodnější možný přístup. Tím se dostáváme k dalšímu faktu, že LP je prostě arogantní blbec neschopný jakékoliv rozumné komunikace, který dokáže akorát kopat kolem sebe bez pádných argumentů, omílajíc při tom pořád dokola svoji propagandu, případně rovnou likviduje nepohodlné příspěvky, vlákna, bug reporty atd.. Někteří lidi mi jej zde dost připomínají, jenom nemají naštěstí tu moc něco mazat a tak jejich blbost budiž uchována až do konce Roota.

Jak systemd komplikuje portování? Tím, že porušuje kompatibilitu spousty věcí a nutí vývojáře buď dělat práci 2x, pro systemd a bez něj? A někteří se pak rozhodnou pro jednu variantu a pokud je to ta se systemd, tak danou část kódu musí někdo další upravovat, aby to fungovalo i na systémech, které "nemají to štestí užívat si úžasnosti systemd"?

Nevyhrožuju, konstatuju. Kdybych chtěl vyhrožovat, tak jedině Leníkovi, ale na to jsou tu jiní a kdybych náhodou chtěl někdy někomu vyhrožovat, tak až v situaci, kdy jsem připraven výhrůžky splnit. Vzhledem k tomu, že mi za to ani on, ani nikdo jiný zatím nestojí, spokojím se s prostým sdělením svých úmyslů světu, přičemž jestli to někoho zajímá, to nechám na každém a zároveň mohu s čistým svědomím prohlásit, že je mi to fuk.

Tak, tím se dostávám k poslední zoufalé větě, myslím jsem ke každému z bodů řekl reálný argument, který jsem si sám z prstu nevycucal, plus jsem jej doplnil řádnou mírou hejtu, což mi zlepšilo náladu. Pac a pusu :*

Jasne. Chlapik spravuje prislusnou oblast nejakou tu dobu, nota bene v Archu... ale vzdycky se najde nejaky webovy anonym, co se takhle zepta.

Co presne je na systemd reliable? Ty asi nectes diskuse.

Ctu. Pomerne znacne mnozstvi stiznosti vede k tomu, ze tazatel si ani neprecetl manual.
Ale presnou statistiku ti z toho neudelam.

Odkud pochází vaše informace, že různé implementace cronu nebude možné používat se systemd?

Pochopitelne placa.

Nerikam, ze nepujde pouzivat cron, ale /etc/crontab. A to take nejde, protoze systemd to resi uplne jinak. Nicmene pry existuje jakysi bastl, ktery crontab prevadi do systemd formatu.

To, ze systemd ignoruje crontab a pouziva svuj vlastni zapis, povede k tomu, ze cron a crontab vymizi a zbyde nam systemd. Takze sbohem prehlednosti, kdy otevru jeden soubor a vidim, co to ma kdy delat.

Nic vám nebrání i se systemd provozovat libovolný cron, který se bude řídit svým crontabem. Jinak crontab není zrovna dobrý příklad, na první pohled to vypadá, že je to jednotný formát, ve skutečnosti ale má každý cron svůj vlastní trochu odlišní formát. Že otevřete jeden soubor a vše vidíte je také nesmysl - máte systémový crontab, uživatelské crontaby a skripty v /etc/cron.*.

Jak dlouho jeste?

systemctl --user

Uz se tesim, az se vsechny prikazy v Linuxu budou jmenovat systemctl --parametr. Uz si predstavuji ty skripty:

systemctl --fgjfgj systemctl --adfru | systemctl --lkdhdj ; systemctl --ofgggm
systemctl --57

To Palo: Nejen zakomentovat ve fstabu, ale také reloadnout systemd:

systemd-fstab-generator is a generator that translates /etc/fstab (see fstab(5) for details) into native systemd units early at boot and when configuration of the system manager is reloaded. This will instantiate mount and swap units as necessary.

Mezitim se ale do debianu dostal systemd, a zmenil u*x OS na generator nahodnych (a nechtenych) stavu.

Zkuste Devuan, tam se zatim BSE nerozsirila.

Software má dělat to, co mu správce řekne. Pokud mu správce řekne, že se to nemá mountovat automaticky, nemá se to dělat automaticky. Ale pokud správce řekne, že se to má mountovat automaticky, má to software udělat.

Což je důsledek té snahy o zpětnou kompatibilitu, kterou tady mnozí vyžadují.

Výhodou toho kompletního refaktoru je to, že se ty chyby odladí už jen jednou a nebudou se vynořovat znovu a znovu s každým přidáním nové komponenty.

Mně by se taky mnohem víc líbilo, kdyby se správa služeb v Linuxu opravila evolučním způsobem, ale podle mne je to v současném stavu už nemožné, těch vrstev různých hacků je na sobě už příliš.

Treba v tom, ze v jedne verzi chodil screen a v dalsi uz ne, protoze Poetteringovi se zhorsila podagra?

Tak vzhledem k tomu, ze cilem neni na systemd spoustet jinou verzi systemd, tak tezko kompatibilni sam se sebou byt muze. Nicmene priklad ukazuje na ucylnou zmenu chovani mezi verzemi, z cehoz buch jaksi usoudil, ze ty verze nejsou kompatibilni.

Kompatibilní se sebou je systemd tak, že novější verze přečte starší nastavení.

A nasledne se chova jinak. To je kompatibilita jak noha.

Změnilo se jen to, co se stane, pokud nějaké nastavení neuvedete. Což je naprosto normální pro všechen software, od jádra až po ten screen.

Aha. Tak me se az dosud zdalo, ze veci mivaji nejake defaulty, ktere maji tendenci drzet napric verzemi a meni se jen vzacne, pokud vubec. V systemd se ale meni jaksi nahodne a bez toho, ze by se nekdo zamyslel a otestoval, co se tim posere. Defaulty nyni asi zalezi na tom, jak se Poettering vyspinkal.

To nevim, ja systemd nastesti nemam. Ale s ohledem na to, ze systemd rad meni chovani mezi verzemi a ze se s novou verzi muze ledacos posrat, tak na stabilitu defaultu spolehat nemuzes.

Ano, ale urcite je vhodne rozlisovat akce na akce, ktere se maji provadet pouze jednou behem startu systemu a na ty, ktere se mohou provest kdykoliv behem behu systemu. Zatim systemd neznam, ale toto by se mi libilo... jde o to mit tu moznost.

U stareho dobreho fstabu a initu ruznych znacek se dala pouzit kombinace voleb auto, noauto, nofail, _netdev a docilit tak konzistentnich a bezpecnych stavu.

Ano, ale urcite je vhodne rozlisovat akce na akce, ktere se maji provadet pouze jednou behem startu systemu a na ty, ktere se mohou provest kdykoliv behem behu systemu. Zatim systemd neznam, ale toto by se mi libilo... jde o to mit tu moznost.

U stareho dobreho fstabu a initu ruznych znacek se dala pouzit kombinace voleb auto, noauto, nofail, _netdev a docilit tak konzistentnich a bezpecnych stavu.

sorry, asi buga v redakcnim systemu, protoze jsem se dvakrat snazil odpovedet na https://www.root.cz/clanky/nebojte-se-systemd-zbyvajici-typy-jednotek/nazory/881439/ a po kazde to tu odpoved zaradilo spatne...

OT: btw. jak se pote, co odpovim na neco v diskuzi, zase jednoduse vratim, tam kde jsem byl pred tim

Jo, NTFS ma directory junction a muzes si tim spojit folders ve Widlich. Soudruzi v Redmondu maji trochu bordel v termitologii.

Aha, to je rozdil, jak noha. Ten vznikl mozna v dobe Widli 95, kdy si nekdo z MS zasel do divadla a byl tak unesen shakespearovskymi metaforami, ze vynutil v MS zmenu termitologie. Pokud se pamatuju dobre, tak u Widli predchozich verzi se v metaforach nikdo nevyjadroval.

The name folder, presenting an analogy to the file folder used in offices, and used in a hierarchical file system design for the Electronic Recording Machine, Accounting (ERMA) Mark 1 published in 1958[3] as well as by Xerox Star....

Tak z tohoto IT prostredi vetsina zde pritomnych opravdu nepochazi. Pochazi naopak z prostredi, kde se nic neBFUizovalo a kde clovek musel vedet, kde co lezi a mluvilo se tvrde o directory.

Nech se vysetrit. Tohle nabadani k nasili vuci neoblibenym vyvojarum neco naznacuje.

Ty se nech vysetrit. Nejaka psychicka porucha te nuti k tomu, abys kazde slovo chapal doslova a do pismene.

Mohl byste mi poradit dotaz, jak se mám Googlu zeptat, co si diskutující NULL představuje pod "modulárností systémů"? Já si pod tím cosi představuju, je to v souladu s tím, co se o modulárnosti systémů a aplikací píše různě po internetu i v knihách, a systemd mi připadá více modulární, než systémy postavené na SysVinitu. Takže tím, že po sobě budeme střílet UTFG, se asi nikam nedostaneme, a nezbývá, než abyste napsal, co je podle vás na systemd nemodulární.

http://0pointer.de/blog/projects/the-biggest-myths.html

Cislo 1.

Na cem _konkretne_ s tim nesouhlasis?