Vlákno názorů k článku Co se systemd… a Linuxem od Heron - SystemD se prosazuje silou. Je jen velmi málo...

Můžu se zeptat, jak počítač vlastně používáte? Mně třeba u web serveru vůbec nezajímá, zda začal startovat, ale zda poskytuje služby nebo alespoň zda běží. Pokud ten web server potřebuje databázi, nestačí mu, že se někdo databázi pokusil nastartovat, ale potřebuje, aby běžela. Vašemu zaměstnavateli asi taky nestačí, že jste vyrazil do práce.

V některých případech to řešit může. Ono někdy může být dost složité nadefinovat, co vůbec znamená "služba běží". Ale pořád je lepší vědět aspoň to, zda vůbec běží příslušný proces.

"nebo alespoň zda běží"

To je informace naprosto k ničemu. Aby webové stránky fungovaly, ano jistě musí běžet webserver. Je to podmínka nutná, nikoliv postačující.

Je tedy zbytečné monitorovat zda běží webserver, zda běží proxy, zda běží dalších sto závislostí. Mnohem přínosnější je monitoravat, zda ten webserver vrací co má. Tím se současně nepřímo zjistí, zda vše nutné běží. Místo x checků stačí jeden. A pokud ten check neprojde, tak admin nemá problém zjistit, zda nějaká služba je kaput. On ten webserver může nakrásně běžet v takovém stavu, že systemd si "bude myslet", že je vše ok a přesto pro uživatele bude daná služba nedostupná.

A to, že služba pracuje jak má a vrací správná data, je něco, co ani nejlepší init systém nezjistí, protože z principu nemůže.

"zda začal startovat"

Takže admin nakonec skončí u informace, kterou má dává i dnešní init, tedy že byl učiněn pokus službu spustit. To, jak nakonec ta služba dopadla ani systemd z principu nezjistí.

Pokud webserver neběží, ve většině případů je potřeba ho nejdřív nastartovat. Kvůli tomu nemusí správce držet službu 24×7, to zvládne i kus software.
Správce neskončí s informací, že služba začala startovat. Má také informaci, zda ještě stále běží. Dále může mít informaci, že služba dala smluveným způsobem signál, že se provedla inicializace. Nebo Systemd ví, že služba přijímá spojení (protože je ve skutečnosti přijímá Systemd a až se někdo pokusí spojení navázat, službu nastartuje a spojení přesměruje).

"Pokud webserver neběží, ve většině případů je potřeba ho nejdřív nastartovat. Kvůli tomu nemusí správce držet službu 24×7, to zvládne i kus software."

Služba startuje společně se startem serveru. Bavíme se o sitaci, kdy služba někdy v minulosti správně nastartovala, proces běží a po čas svého života se dostala do nestandardní situace, která vede k tomu, že vrací nesprávná data. Jeden by si myslel, že to je z kontextu diskuse jasné.

"Má také informaci, zda ještě stále běží"

To snad uvidí i z výpisu procesů, na to nepotřebuje systemd.

"protože je ve skutečnosti přijímá Systemd"

A kdo hlídá hlídače? Co když je to právě systemd, který se dostal do nestandardní situace a data odesílá špatně nebo je třeba nepředává vůbec?

Stejně tam ten check, jak jsem ho popsal, být musí.

Ano, to máme hezky popsaný případ, který je příliš obecný a nelze jej řešit pouhým zaškrtnutím nějakého příznaku ve správci služeb. Takže to, že to neumí, bych nevyčítal žádnému správci služeb.
Vedle toho ale máme případ, kdy služba správně nastartovala, proces běží a během života procesu dojde k nějaké nestandardní situaci, která způsobí ukončení procesu. A to je ten případ, o kterém jsem psal já. V takovém případě většina správců u většiny služeb tu službu znovu nastartuje, a pak zkoumá, proč ta služba havarovala. Na to zkoumání pak má hodiny a dny, na nápravu často týdny nebo měsíce - a nebo se v nezanedbatelném počtu případů ukáže, že se nepodařilo zjistit, v čem je problém, nebo by oprava problému byla tak nákladná, že se nevyplatí.
Celý ten proces - monitoring po x minutách otestuje dostupnost serveru a zjistí, že je nedostupný - pošle se SMS - správce se vzbudí a nadává, že webserver opět překročil limit paměti, což se dvakrát za rok stává a nikdo neví proč - správce se přihlásí přes SSH a web server znovu nahodí -počká, jestli server naběhl - správce znovu uléhá a ráno se podívá, jestli příčina výpadku byla stále stejná - tedy celý tento proces se dá nahradit malým kouskem softwaru, který když dostane signál, že se sledovaný proces ukončil, pokusí se jej nastartovat znova. A teprve pokud se to třeba napotřetí nepodaří, ohlásí chybu (a mezi tím už i onen monitoring webu zaznamenal výpadek a správce dostal SMS). Ano, správce pak nevypadá tak důležitě, protože všichni okolo nevidí, že něco nefunguje a že to správce musí nahodit. Ale zase na druhou stranu správci nechodí v noci tolik SMS, které vyžadují jenom to, aby napsal /etc/init.d/a­pache2 zap start.
Ano, u důležitého serveru musí být i ten externí monitoring, to nikdo nezpochybňuje. Ale to přece neznamená, že i banální stavy, u kterých je postup obnovy jednoduchý a jasně daný, se musí řešit přes monitoring a hlavně živého správce.

On ten monitoring ovšem nemusí poslat jen sms a dál tupě zírat do zdi. On úplně klidně může ty služby restartovat sám (resp. se na základě monitorované situace spustí nějaký skript, který se o to postará). Právě a jen v případě, že konkrétní check dosáhne konkrétní hodnoty, kterou tam zadal admin v případě, že tohle nastane.*

Upřímně řečeno, já si ani nepamatuju, kdy naposledy jsem vstával k vůli tomu, že nějaký proces neběžel. Nechci říct nikdy, ale to se prostě nestává. Mnohem častěji se stává právě ono něco mezi (a ani to nenastává nijak často). Služba běží, ale OOMK odstřílel pár podprocesů, takže běží ale divně. Tohle se stane jednou a potom se nastaví parametry lépe (RAM > součet paměti všech procesů nebo tak něco). Nebo moje "oblíbená" MySQL (která mi sice už pár let do domu nesmí, ale bohužel některé staré projekty musí bůh ví proč běžet), se rozhodně, že po milionté rozbije myisam tabulky. Na tohle opravdu restart nepomůže.

Takže po čase ony se ty jednoduché případy (kdy by možná pomohl restart) stejně vyřeší a potom z monitoringu chodí jen ty netriviální věci.

*) A ne, opravdu nechci, aby součástí systemd byla ještě icinga a munin. Opravdu ne. Je mnohem univerzálnější, když to zůstane oddělené.

"Docela by mě zajímalo, jaký software to někteří zdejší diskutující používají, že jim (asi) neustále padá jak jablka ze stromu a zároveň evidentně nepoužívají žádnou monitorovací službu (anebo ji neumí pořádně nastavit)…"

Hehe, to mi připomnělo situaci, kdy jsme jedné nemalé organizaci dodávali servery a oni se nás, zcela vážně ptali, jak často je mají restartovat. Po chvíli naprosto nechápavých pohledů nám sdělili, že minulý dodavatel (asi tak 5000x větší jak my) technologíí jim doporučoval restart alespoň jednou týdně. Nám naše servery běží tak dlouho, dokud nevyjde kritická oprava nějaké vzdáleně zneužitelné chyby, jinak servery (což pochopitelně platí i pro služby, ty se prostě bezdůvodně nerestartují) mají uptime 500 i víc dnů. Pokud vím, tak námi dodávané servery (pro danou organizaci) nebyly restartovány od nasazení před lety ani jednou. Zda je to dobře nebo špatně nechávám stranou, osobně rád restartuju po každém updatu prostě jen abych měl jistotu, že vše najede. Ale pokud updaty nejsou, tak ať to běží dva roky v kuse, není problém.

Tak já například používám TinyDNS s daemontools, protože je to nejjednodušší a autorem doporučený způsob použití - o žádné havárii nevím. Používám Postfix, protože je tak napsaný - o žádné havárii nevím. Používám daemontools pro běh různých dalších služeb (třeba i jen rychle naskriptovaných), protože se můžu spolehnout, že pokud to bude možné, ta služba poběží - a nemusím se o to starat. Používám WebLogic s jejich node managerem - vím o případech, kdy se server dostal do chybového stavu ale běžel, správci jej museli restartovat ručně. A také vím o menším množství případů, kdy server spadnul (kvůli chybě JRockitu) a node manager jej restartoval. Snažíme se ty první případy převést na ty druhé, protože když se zblázní JVM, je její ukončení to nejlepší, co se dá udělat.
Monitorovací služba slouží k monitoringu, ne k udržování služeb v běhu.

Kdysi dávno apache2+mod_php, taky si pamatuju na občasné výpadky dovecotu, ale ty mohly být způsobené i tím naším custom autentizačním modulem.

Z nedávné doby gitlab-sidekiq service (než jsem to překopal na systemd service), tak se pouštěl gitlab + gitlab-sidekiq z jednoho init.d skriptu, který dodával upstream. A když zdechl sidekiq, tak nejely různé joby na pozadí, což se nedalo na první pohled zjistit. Pak pomohl upgrade ruby a mám pocit, že to od té doby už tolik nepadá (každopádně to nevím, neb to supervizor případně znovu nahodí).

Pro ten externí monitoring je mnohem složitější rozpoznat, že jenom havaroval nějaký proces. Navíc nejspíš provádí kontrolu jednou za čas, ale správce služeb se o havárii procesu dozví v ten okamžik, kdy se proces ukončí.
OOMK může stejně tak zabít hlavní proces. Navíc pokud nějaká aplikace používá podprocesy a neumí se o ně postarat - má to nechat na správci služeb, který to umí :-) I kdyby se ty jednoduché případy po čase vyřešily, není do doby, než se vyřeší, důvod nestartovat služby automaticky. Přičemž moje zkušenost je taková, že některé problémy se postupem času podaří vyřešit, a jiné zase vzniknou. Hlavně ale nechápu, k čemu je dobré nechávat tu službu po pádu vypnutou (samozřejmě kromě výjimek typu porušená databáze). Někdo pravděpodobně chtěl, aby ta služba běžela, tak by se snad správce služeb měl postarat, aby opravdu běžela. Pokud to tak nechce, nastaví službu do režimu "jednou spustit a dál si toho nevšímat".
Mimochodem, i autoři původního SysVinitu byli toho názoru, že některé služby mají běžet pořád ať se děje co se děje, a pokud se z jakéhokoli důvodu ukončí, je potřeba je znovu nastartovat. Proto má akci respawn.

"Navíc pokud nějaká aplikace používá podprocesy a neumí se o ně postarat - má to nechat na správci služeb, který to umí :-)"

Nejde o ty podpocesy samotné. V Unixovém světě je běžné, že pokud něčemu pošlu SIGTERM, proces se spořádaně ukončí. Stejně tak je běžné, že se s každou novou síťovou konexí ten proces vytvoří.

Bohužel, programátoři některých frameworků používají pooling spojení (což je jiště hezká věc), ale ten pooling je napsaný tak blbě, že nepozná nefunkční spojení. Což může být i krátký výpadek sítě apod, ne jen selhání onoho procesu.

Takže problém není v tom, že ten původní proces nežije (on se při dalším spojení opět vytvoří), problém je v tom, že nějaká úplně jiná služba třeba na úplně jiném serveru ten proces vyžaduje. A jako řešení není restartovat onu službu s tím spadeným procesem, řešení je vylejt ten pool spojení.

Což je něco, co admin ví a co opět žádný init systém na světě nevyřeší.

Ale tady už se dostáváme do oblastí našich konkrétních každodenních zkušeností. Já problém s padajícími službami, který se vyřeší jejich opětovným nahozením nemám. Služby prostě nepadají. A většina hlášení, které z monitoringu chodí, mají jakýsí netriviální charakter. Prostě jen proto, že se za těch x let provozu všechny ty triviální záležitosti vychytaly.

Jestli má někdo problém, který se vyřeší opětovným spuštěním služby, ať si klidně používá systemd. Je to jeho volba. Ale ať mi toto volbu nikdo nenutí.

Řekl bych, že popisuješ problém nezdravé služby, který se má přece opravit a pak už žádný problém nebude. Jinak to, že nějaká aplikace špatně používá pool spojení, podle mne vůbec nijak nesouvisí se správcem služeb. Není potřeba vyjmenovávat všechny možné problémy, které správce služeb neřeší – správce služeb má za úkol udržet v chodu nějakou službu. Nic víc.
Myslím, že Systemd nikdo nikomu nenutí. Naopak, dobře napsané aplikace budou dobře fungovat ve Systemd, a jiný init/rc systém si s nimi určitě také poradí.

Fajn, jsem rád, že jsme se konečně shodli na tom, že reálné problémy, které vznikají, init systém stejně nevyřeší a je potřeba je řešit na místě, na kterém vznikly. :-)

"Myslím, že Systemd nikdo nikomu nenutí."

To není pravda, jak už tady bylo mnohokrát uvedeno. Na systemd závisí spousta věcí, která by vůbec nemusela. Pokud chci danou věc používat, mám na výběr zda si budu složitě udržovat verzi bez systemd, nebo se prostě podřídím. Většina lidí evidentně volí ono podřízení.

Ano, reálně ještě stále jde se systemd vyhnout a zatím to tak moc nebolí (to, že nemůžu používat gnome mě zas tak netrápí, stejně má jako závislost další sračku v podobě PA), ale systemdmizace linuxu zdárně pokračuje dál. Takže nakonec nezbude nic jiného, než linux trvale opustit.

Že správce služeb nevyřeší všechny problémy, které mohou nastat, to je snad samozřejmé a nic jiného jsem nikdy netvrdil. Systemd dělá to, co lidé očekávají od správce služeb – tj. když mu řeknou, že má běžet web server, tak Systemd dělá vše, co je v jeho silách, aby web server běžel. SysVinit se v takovém případě pokusí server nastartovat, a tím skončí – což rozhodně není vše, co se pro splnění toho úkolu dá udělat.
Ty věci, které na Systemd závisí, z toho asi mají nějakou výhodu, ne? Proč by to jinak jejich autoři dělali. Ano, pokud si někdo chce udržovat jinou verzi, musí do toho investovat. Když je nějaký program pro unixové systémy, a já budu chtít verzi pro Windows, je to taky moje starost, abych si jí upravil a udržoval. Nebo si mám stěžovat, že autoři podporují jen unixové systémy, a mám nadávat autorům Linuxu, proč autorům toho programu poskytuje služby, které chtějí používat?

"Že správce služeb nevyřeší všechny problémy, které mohou nastat, to je snad samozřejmé a nic jiného jsem nikdy netvrdil."

A jak dokazuje i tato diskuse, tak systemd neřeší nic víc, než stávající systémy.

"SysVinit se v takovém případě pokusí server nastartovat, a tím skončí – což rozhodně není vše, co se pro splnění toho úkolu dá udělat."

Boha jeho, to je fakt jak do dubu. sysVinit spustí skript. Jestliže v tom skriptu bude while (true) { služba --start; } tak se ta služba bude, přesně dle přání správce, po pádu opakovaně spouštět. Na to není potřeba systemd.

"Proč by to jinak jejich autoři dělali."

Protože třeba ti autoři nevědí, jak se to dá dělat jinak a lépe. Ne, tohle není urážka. Tohle je o tom dělat věci s jakousi pokorou a vědomím, že nejsem dokonalý. Proto je potřeba se podívat, jaké všechny existující prostředky existují, proč existují a naučit se je používat. Jak jsem už psal, podle mě tihle autoři vůbec nemají páru o tom, jak se některé věci mají (a nebo, aby to nebylo tak tvrdě řečeno: mohou) dělat.

"Když je nějaký program pro unixové systémy, a já budu chtít verzi pro Windows"

Pěkný pokus. Nevyšel. Mluvíš o unixových systémech. Dosud se (většina) "linuxových" (či spíše unixových) programů psala tak, že nebyl větší problém je rozběhat na téměř libovolném unixu (linux, bsd, solaris apod, stačí dodržovat posix v nějaké obecné variantě). Systemd jde záměrně směrem, že je linux only. A každý program, který se mu podaří nakazit, bude od té doby také linux only.

Někteří uživatelé údajně nepotřebují nic víc z toho, co Systemd nabízí. To dokazuje tahle diskuse. A také dokazuje, že pro některé uživatele to řeší víc – třeba to, že místo svaté dvojice init/rc doplněné třeba o daemontools mohou používat jediný balík, který se chová konzistentně.
Ano, SysVinit spustí skript, nic jiného nedělá – to hlídání služby případně už musí řešit ten skript. Takže se vlastně dá říct, že SysVinit nedělá nic jiného, než co umí shell, a tudíž nepotřebujeme ani SysVinit.
Nebo třeba ti autoři naopak vědí, jak se to má dělat jinak a lépe. Mně třeba připadá správný ten koncept, že služba je normální proces, který běží na popředí, informace vypisuje na standardní výstup a chyby na chybový výstup a reaguje na běžné signály. Výhodou je třeba to, že proces běží úplně stejně, ať ho spustím z příkazové řádky nebo přes správce služeb. Daemoni a dvojitý fork, abych se dostal z dosahu rodičovského procesu, to je podle mne omyl přírody.
Já jsem ale psal, že chci ten unixový program rozběhat na Windows. Ale i když budou vznikat linux only programy – pokud je ten program opensource, nikomu přece nic nebrání udržovat kód, který bude na Systemd nezávislý. Nikomu nic nebrání implementovat tu samou funkcionalitu i do jiných systémů.
Mimochodem, které jsou ty vlastnosti, které „nutí“ autory programů být závislý na Systemd a na Linuxu?

"Mimochodem, které jsou ty vlastnosti, které „nutí“ autory programů být závislý na Systemd a na Linuxu?"

To je snad jasné. Systemd vyžaduje cgroups, což je, jak jistě všichni víme, součást Linuxu. Nikde jinde není. Takže dokonce ani nemůžu provozovat systemd sice na Linuxu, ale bez cgroups...

Tedy, pokud něco závisí na systemd, a systemd běží jen na Linuxu, tak je ta věc automaticky linux only.

A co je to „něco závisí na Systemd“ a jak to na něm závisí?

"Boha jeho, to je fakt jak do dubu. sysVinit spustí skript. Jestliže v tom skriptu bude while (true) { služba --start; } tak se ta služba bude, přesně dle přání správce, po pádu opakovaně spouštět. Na to není potřeba systemd."

Tohle přece nebude fungovat, ne? SysVinitu přece musí vadit, že se ten script neukončí.

Pokud se ten skript forkne a uteče z dosahu initu, tak to SysVinitu vadit nebude.

A už se nám to začíná komplikovat. A další komplikaci do toho vnese například požadavek na zastavení takové služby.

Ale přesně o tom to je, napřed se řekne, že to jde jednoduše a pak se to komplikuje a komplikuje ...

Jaký přesně by byl správný postup v případě těch vážných problémů (chyby sw v okrajových podmínkách, pokus o bezpečnostní průnik, odcházející hw)? Nechat službu zastavenou do doby, než se problém vyřeší? Nebo to, že musí správce službu nastartovat ručně, jej má motivovat, aby problém řešil? Tak pak ať si líní správci, kteří potřebují takovouhle motivaci, dál používají SysVinit, a ti svědomití budou používat Systemd...

Když už diskuse došla do fáze nočního vstávání po smsce z monitoringu, tak právě tohle je ta největší motivace. .

liquidwater (hezký nick :-)) to napsal naprosto přesně. Pokud jakýsi obskurní (snad jsem to napsal dobře) systém tu službu udrží tak nějak v chodu, je to jednak odkládání problému do bodu, kdy jej bude daleko složitější vyřešit (protože například může zafungoval i silent data corruption, které se může zpropagovat do záloh a pokud se vydrží chybu ingorovat dostatečně dlouho, tak i data na všech zálohách budou vadná) a hlavně admin nemá žádnou motivaci problém vyřešit, protože ho to prostě nepálí. Když se k vůli tomu nevyspí, tak se bude hodně snažit, aby už ho to nikdy nevzbudilo.

"Nebo to, že musí správce službu nastartovat ručně, jej má motivovat, aby problém řešil?"

Opakuješ se jak kolovrátek. Drtivá většina případů není jen restart služby. Zdravé služby nepadají. To, že to spadlo je indikátorem něčeho složitějšího. Tím, že se to jen restartuje a ono to naběhne a jede se dál se nic nevyřeší.

Dobře, takže správce, který potřebuje, aby mu služba neběžela, aby s ní začal něco dělat, nebude tuhle funkci používat. My ostatní ji klidně použijeme, protože víme, že bychom službu po pádu stejně nejdřív ručně nahazovali - což může lépe a rychleji udělat software. A my se pak místo restartování můžeme věnovat řešení problému. Pokud někde hrozí silent data corruption, může se služba nastavit do režimu, že nastartuje jen jednou, nebo ještě lépe může se nastavit do režimu, že se po pádu provede kontrola dat a teprve pokud dopadne dobře, služba se nastartuje.
Ano, zdravé služby nepadají. Jenže je naivní myslet si, že je veškerý software bezchybný. Ony to ty služby na sobě nemívají napsané "tato služba bude padat". Zajímalo by mne třeba jak ozdravit tu službu, kde třeba dvakrát za rok spadne JVM. Nasimulovat to reálně nejde, a i kdybychom to dokázali nějak rozumně reportovat výrobci, dozvíme se, že máme upgradovat na nejnovější verzi. Která bude mít zase jiné chyby. A i kdyby se to celé podařilo, chybu jsme nahlásili a výrobce ji na náš popud opravil, bude to celé trvat několik měsíců - jak pomůže, že ten server budou muset plus mínus dvakrát ročně správci restartovat ručně?
Opakuju se jako kolovrátek, protože ignoruješ, co jsem napsal. "Drtivá většina případů" není argument pro to dělat to ve zbytku případů ručně.
Jinak pokud zdravé služby nepadají a nechybují, není ani důvod řešit nějaké restartování z monitoringu. Pokud služba neběží z toho důvodu, že se ukončil příslušný proces, je v drtivé většině případů správné řešení proces opět nastartovat. Pokud to bude chtít řešit monitoring, stejně musí spolupracovat se správcem služeb, dotazovat se na stav procesu, jestli nejde o plánované vypnutí - a proč to všechno, když o ukončení procesu ví správce služeb dřív, než monitoring, a má všechny dostupné informace proto, aby rozhodl, zda jde o tento případ?

> My ostatní ji klidně použijeme, protože víme, že bychom službu po pádu stejně nejdřív ručně nahazovali - což může lépe a rychleji udělat software

Jak Vas tak pocuvam, zacinam mat pocit, ze by bolo najlepsie, keby "vas ostatnych" radsej nikto k ziadnemu serveru nepustal :)

Nebolo by najlepsie do toho systemd pridat automaticky restart po 2 dnoch behu? Na NT Serveroch to vraj pomaha :)

Chcete diskutovat se mnou, nebo si sám budete vymýšlet hloupé protiargumenty, abyste je následně slavnostně rozcupoval? Když jsem napsal, že existují služby, které je po případném pádu potřeba nejprve restartovat, očekával bych jako polemiku argumenty, proč žádná taková služba neexistuje a co je vždy potřeba udělat jiného, co brání restartu služby.

Dobře, takže máme web server, který servíruje statické soubory (uzel nějaké CDN). Jaké škody napáchá, když se ten server po pádu restartuje? Jaké škody napáchá, když se po pádu restartuje SSHD?
Mimochodem, proč vůbec používáte nějaký init/rc systém? Když dojde k výpadku proudu a systém se před úplným vybitím UPS vypne, nemůže se po zapnutí proudu sám nastartovat. To by mohlo napáchat daleko víc škody než užitku. Takže vy k serveru přijedete, ručně jej zapnete, přihlásíte se do terminálu, vše zkontrolujete a začnete postupně startovat jednotlivé služby. Síť, SSH server, produkční služby… K tomu žádný init/rc systém nepotřebujete, naopak by škodil. Když nainstalujete novou verzi jádra, je to to samé. Nemůžete jen tak nastartovat systém, to by mohlo napáchat víc škod, než užitku. Takže stejně, přihlásit do terminálu, vše zkontrolovat, postupně ručně nastartovat. Takže vy vlastně žádný init/rc systém nepoužíváte, stačí vám samotný init, který připojí terminály. Proč vůbec řešíte nějaký Systemd?

"Když dojde k výpadku proudu a systém se před úplným vybitím UPS vypne"

Ehm, srovnávat korektní vypnutí a následné zapnutí celého serveru se službou, která spadla (to není korektní vypnutí), to už je hodně silná káva.

Ukončení služby nemusí vždy znamenat nekorektní vypnutí. Spousta služeb je záměrně navržena tak, že se s nekorektním ukončením počítá. Pokud budeme počítat jen s korektním ukončením, nepotřebujeme žádné žurnály ani v souborových systémech, ani v databázích. Naopak pokud je služba dobře navržená, restart po nekorektním ukončení nenapáchá žádné škody (protože se služba buď dokáže zotavit, nebo se odmítne znovu nastartovat). No a pokud mám takhle navrženou službu, proč ji po pádu hned nenastartovat?
Přesně tenhle princip se přece používá u žurnálovacích souborových systémů. Ve „zdravém systému“ žádný žurnálovací souborový systém není potřeba, protože přece nikdy nedojde k nekorektnímu ukončení/odpojení – není dokonce potřeba ani fsck. Přesto si většina administrátorů myslí, že mít fsck a žurnálovací souborový systém je dobrý nápad – protože nikdo nedokáže zajistit, že se opravdu nikdy nic nestane. Většina serverů je také nastavena tak, že se po zapnutí prostě připojí disky v režimu zápisu tak, jak mají být za normálního běhu. Nikdo nezkoumá, zda došlo ke korektnímu nebo nekorektnímu vypnutí – prostě se příslušný správce (mount) pokusí službu nastartovat (disk připojit). A je věcí toho souborového systému, aby zkontroloval, zda je souborový systém v pořádku a připojil jej, opravil se, nebo aby se odmítl připojit s tím, že je to chyba, kterou sám nedokáže opravit. No a žurnálovací souborové systémy jdou v tomhle ještě dál, zefektivňují tu úvodní kontrolu a opravu chyb – přesně z toho důvodu, že když dojde k problému, nikdo nechce čekat, až správce disk přimountuje ručně, dokonce ani nikdo nechce čekat, než se celý souborový systém zkontroluje. Prostě má po výpadku začít co nejdřív poskytovat služby, a analýza problému a oprava, aby k němu příště nedošlo, se může řešit paralelně vedle toho.

"Spousta služeb je záměrně navržena tak, že se s nekorektním ukončením počítá."

To jistě ano, ale tohle už úplně uhýbá z tématu předchozí diskuse. Tématem předchozí diskuse je to, že služba spadne z dosud neznýmých příčin.

"Pokud budeme počítat jen s korektním ukončením"

Nic takového tady nikdo netvrdil. Až ty jsi přišel se srovnáním korektně vypnutého serveru a tím, že ho nějaký admin musí před zapnutím zkontrolovat. Což je mimo mísu.

" Nikdo nezkoumá, zda došlo ke korektnímu nebo nekorektnímu vypnutí"

To přece není pravda. Teda, ve vaší organizaci to asi pravda je... Přece příčina vypnutí je dost podstatná informace před tím, než se ten server pokusím znovu zapnout. Ať již se jedná o fyzický či virtuální. Pokud jen vypadl elektrický proud, je to jiná situace, než když došlo k nějakému fyzickému selhnání. Fyzicky poškozený server asi zapínat nebudu, vyndám z něj disky a pokusím se z nich dostat data. (Pokud nejsou na záloze.) Není to tak dávno, co v jednom datacentru technologii prolila voda z prasklé trubky. Ty bys takový server prostě zapnul, protože přece nikdo nezkoumá, zda došlo k nekorektnímu vypnutí.

Pokud se jedná o vmka, je velký rozdíl, zda došlo prostě k ukončení například vlivem toho, že fyzický server někdo odpojil od elektřiny, nebo proto, že něco porušilo data virtuálního disku.

Možností, co se mohlo stát, je spousta. Pokusit se to "prostě zapnout" může situaci významě zhoršit. Odpovědný admin tohle neudělá.

Ne, není to uhýbání od tématu předchozí diskuse. Připojení souborového systému po nekorektním ukončení je start po pádu z neznámých příčin. Start databázového serveru po nekorektním ukončení je start po pádu z neznámých příčin. Proto je to zotavení po havárii – pokud je příčina předem známá, zdravá služba na ní zareaguje a k pádu vůbec nedojde.
Příklad toho „jednoho datacentra“ je dobrý. Tam někdo zkoumal, zda si ten který klient přeje server nastartovat? Já myslím že ne, že virtuální servery prostě nastartovali, a servery, které nevypadaly, že by jimi protekla voda, prostě zpátky připojili na napájení.
Jinak já jsem samozřejmě nepsal o případu, kdy serverem protekla voda. Ale pokud jen vypadl elektrický proud, asi nevyndaváš disky a nepokoušíš se z nich dostat data. Když jenom vypadne proud, co vlastně děláš jiného, než že server zapneš a necháš ho normálně nabootovat – a teprve pokud by se to nepodařilo, budeš řešit to, co při bootu selhalo?

Tak ještě jednou tvoje slova:

"Nikdo nezkoumá, zda došlo ke korektnímu nebo nekorektnímu vypnutí"

vs.

"a servery, které nevypadaly, že by jimi protekla voda, prostě zpátky připojili na napájení."

Tak zkoumá nebo nezkoumá? Když nezkoumá, tak jak ví, že jimi neprotekla voda?

"Když jenom vypadne proud, co vlastně děláš jiného, než že server zapneš a necháš ho normálně nabootovat – a teprve pokud by se to nepodařilo, budeš řešit to, co při bootu selhalo?"

Když vím (tím, že zkoumám příčiny vypnutí), že jenom vypadl proud, tak server normálně zapnu a dohlédnu na to, že všechny služby spolehlivně nastartovaly. U mých osobních serverů ještě rád provedu fsck -f, nebo btrfs scrub, prostě jen pro moji jistotu (což ostatně dělám sem tam jen tak, protože se mi líbí průběh a výstup xfs_repair, ale osobní úchylky nechme stranou).

Tím „nikdo nezkoumá…“ jsem myslel případ, kdy se prostě server pustí – buď ho někdo zapne „vypínačem“, nebo je nastaven pro automatický start po výpadku napájení a napájení je obnoveno. Psal jsem tedy o vypnutí serveru jako nějaké logické jednotky, nemyslel jsem tím přímo fyzický server.
Pokud u každého zařízení musíš fyzicky být, abys zjistil příčinu výpadku a pak jej zapnul, asi máš všechna zařízení na jednom místě. Když někde přejde bouřka nebo jen vypadne proud, úplně stačí osobně obcházet ty routery, switche, NASy a podobná zařízení, která mají po obnovení napájení automaticky naběhnout, ale nenaběhnou. Nedovedu si představit, že by takhle někdo ručně zapínal všechno.

"Pokud u každého zařízení musíš fyzicky být, abys zjistil příčinu výpadku"

Nemusím. To, že někde vypadl proud se obvykle ví, to není černá magie.

> Jaké škody napáchá, když se ten server po pádu restartuje? Jaké škody napáchá, když se po pádu restartuje SSHD?

To sa fakt chcete hrat tymto sposobom? Staticky webserver pre CDN nema prilis dovodov spadnut, ale ked uz fantazirujeme - ak sa zosype kvoli chybe na disku a systemd ho bez hlesnutia restartuje, bud sa dostane do stavu, ked pri kazdom requeste spadne znovu, alebo zacne servovat nezmyselne data. Klienti CDN dostanu poskodene data, ktore nasledne v lepsom priade neprejdu checksumom a budu sa tahat stale dookola... Nez to admin restartujuceho typu zacne riesit, tyzden nebude nikto tusit, co sa deje.

A to je ten lepsi pripad. V horsom pripade vam staticky webserver pada kvoly nejakemu script kiddie, ktore skusa spustit kod cez este neopatchovany exploit. V pripade neuspechu mu ho restart urcite pomoze :)

Ako Vam uz povedali viacery predomnou, v *nixovom svete sluzby nepadaju. Preto aj spominal ten Windows NT a preto i pan predomnou asi "widliho admina" spominal. Pretoze "riesenie", o ktorom hovorite Vy a vlastne i cely pristup k veciam okolo systemd velmi pripomina ten MS-styl, kde sa vsetky prusery riesia az v momente, ked uz su tak enormne, ze sa nedaju ignorovat.

> Ako Vam uz povedali viacery predomnou, v *nixovom svete sluzby nepadaju

Bohuzel musim oznamit vam a viacerym pred vami, ze padaji, smirte se s tim. Dalsi novinkou pro vas asi bude, ze jsou situace, kdy je proste nejjednodussim a pritom dostatecne dobrym resenim to nechat automaticky restartovat.

Chapu, ze jsou situace, kdy jedinym spravnym resenim je zavolat admina, aby se v tom tyden vrtal a pak slavnostne se 100% jistotou rekl, ze data jsou ok a pricinu nenasel, jedeme dal.

Ale taky vy pochopte, ze jsou situace, kdy je proste dost dobry jet dal rovnou.

> Situace kdy je "dobry jet dal rovnou" ... NEEXISTUJE.

Ach jo, vy jste tady sami zkuseni teoretici. To vas mam jako prosit, abyste mi uverili, ze toto byl normalni stav, kdy sluzba ve svete nixu obcas spadla a bylo uplne v poradku ji nastartovat a jet dal? Podotykam, ze takovy stav trval nekolik let a firma na nem je zavisla. Na datech se delaly inkrementalni zalohy ktere nikdy nebyly poskozeny a nikdy nebyly potreba pro recovery, protoze nikdy nedoslo k poskozeni dat. Takze to bylo uplne normalni, velmi levne a pritom ucinne reseni.

Dle vasich teoretickych superbezpecnych opatreni byste asi doporucili, aby se firma preorientovala na prodej rohliku, ze?

> Dle vasich teoretickych superbezpecnych opatreni byste asi doporucili, aby se firma preorientovala na prodej rohliku, ze?

Ano. Celkom vazne. Alebo, aby to neznelo tak hrubo, vsetko OK, ale ak ta firma nejak suvisi s IT, poprosim nazov. Aby som s nou nahodou niekedy v zivote nemal nieco spolocne.

Inak ja si viem predstavit situaciu, ked ma clovek na krku daku zdedenu vec, z ktorou nemoze robit nic a pady riesi restartom. Aj ked musim priznat, ze som sa s takou stretol zatial vzdy len na Windowsoch. Cize ano, verim, ze stav, aky popisujete moze nastat. Ale je to okrajova a nestastna situacia a riesenie restartovanim je otazkou 2 riadkov skriptu. Fakt nechapem, preco to rvat do initu a preco to nasledne hlasit za uzasnu, absolutne nevyhnutnu featuru a tvarit sa, ze je chybou, ak tato moznost chyba ostatnym initom.

Nebylo to zdedene ale novy sw, ktery jeste nebyl optimalizovany a pri odesilani velkych kvant dat dosla pamet a padalo to. Pak bylo nutno operaci opakovat aby odeslal i zbytek. Nicmene melo to jinak tak dobre vlastnosti, ze jsme to nasadili, obcasne preruseni sluzby za to stalo. Po par letech doslo i na tu optimalizaci... :-) Monitoring a restart se resil monitem, jestli to cpat do initu nevim.

Můžu se zeptat na jeden konkrétní příklad takové chyby, jak byste ji opravil? Máte server, v něm ECC paměti, na serveru nějakou normální unixovou službu, která nemůže nikdy spadnout. Slunce má zrovna živější období, pošle nám sem spršku nějakých zajímavých částic, a co čert nechtěl trefí se zrovna do naší RAM a dva bity překlopí. Dva bity už jsou moc, to ECC nedokáže opravit, jenom to detekuje. Ale s procesem, který má poškozenou paměť, se toho moc rozumného dělat nedá, jedině ho okamžitě zabít, dřív, než s tou poškozenou pamětí začne pracovat a někam jí zapíše nebo pošle nebo se pokusí provést. Takže nám ta služba, která nikdy nemůže spadnout, tak nějak spadla.
Jak se má tahle chyba opravit?

:D

V takomto pripade je celkom zrejme nutne nechat sluzbu padnut a privolat admina. Ten po detekovani priciny problemu zariadi workaround zabalenim serveru do alobalu, alebo nasadenim oloveneho platu.

Žádný software nemá příliš důvodů spadnout. Pokud dojde k chybě na disku, nemusí ten webserver nutně spadnout – takže ta chybná data bude odesílat bez ohledu na restart. Pokud admin neřeší problém, není to chyba žádné aplikace. Jinak ten server může spadnout kvůli chybě v programu, kvůli chybě v paměti, kvůli překročení nějakého limitu (třeba kvůli memory leaku)… Nic z toho nebrání tomu server znovu nastartovat, a problém řešit při nastartovaném serveru.
Pokud webserver padá kvůli script kiddie (jak to, vždyť provozujete jen bezchybný software), jak pomůže, že ten server zůstane dole? To ho správce nechá vypnutý, bude zkoumat logy, z nich vyvěští, že to byl exploit, počká na opravu a teprve pak server znovu zapne?
Pokud ve vašem světě služby nepadají, nechápu, proč řešíte nějaké neexistující epxloity nebo neexistující chyby disku. A taky proč vůbec řešíte automatický restart po pádu služby – když ve vašem světě služba nikdy nespadne, nedojde nikdy ani k tomu automatickému restartu.
Ten váš popis „widliho admina“ nijak nesouvisí s tím, o čem se tady diskutuje. Automatický restart služby neimplikuje to, že se průsery řeší až v okamžiku, kdy jsou enormní. Automatický restart služby vůbec neznamená, že se problémem nebudu zabývat. Naopak dává správci možnost zabývat se problémem dřív, protože se nemusí starat o to, aby služba vůbec běžela.
Zkuste si to představit na něčem kritičtějším. Pokud dojde k nějakému problému za letu v letadle, které řešení byste preferoval – to vaše, kdy se piloti přestanou věnovat pilotování a budou spoléhat, že to nějak dopadne (nejspíš na zem nebo do moře), a místo toho budou vše důkladně analyzovat, aby si byli jistí příčinou problému dříve, než se pokusí obnovit řízení letadla – nebo to moje, kdy je potřeba nejprve obnovit ovládání letadla a pokud možno s ním přistát, a teprve pak v klidu na zemi ať si to týmy expertů zkoumají klidně měsíce? Nebo se zase dozvím, že ve vašem světě letadla nepadají?

"Pokud dojde k nějakému problému za letu v letadle"

Mě celkem mrzí, že jsem neodeslal komentář s jaderným reaktorem, teď to bude vypadat, že se snad od tebe inspiruji.

Jaderný reaktor byl odstaven po té, co se dostal do nestandardního stavu (memory, ehm, radiation leaky). Vy byste reaktor restartoval a potom v klidu řešil, proč došlo k příčině odstavení. Nakonec k leakům dochází jen 2x za rok. Moje pojetí IT má daleko blíže k řízení jaderné elektrárny (podobný příměr jsem použil před 5 lety při zavádění pohotovosti u nás ve firmě).

"se pokusí obnovit řízení letadla"

Oni se pokusí obnovit řízení letadla právě na základě těch informací. Nemá smysl zkoušet nastartovat levý motor, když je urvané celé levé křídlo.

Jinak to nebyl dobrý příměr. Ti piloti se navíc pokusí o co nejbezpečnější havarijní přistání tak, jak je to za daných podmínek možné (k tomu ty podmínky musejí znát). Na zemi potom je to letadlo odstaveno a důkladně prozkoumáno techniky. A také se stává, že je globálně zakázán provoz daného typu letadla, dokud se příčina neobjasní.

Ve vašem pojetí je to letadlo dál využíváno a normálně se s ním létá. Protože při příštím startu prostě normálně vzlétlo, tak vo co de, že.

Pokud byl jaderný reaktor odstaven, není požadavek, aby běžel, ale naopak, aby byl odstaven. Během normálního provozu se neodstavuje kvůli každé nepřesnosti, naopak je tam spousta automatických mechanismů, které nejrůznější chybové stavy automaticky řeší. Nečeká se pokaždé na operátora, aby provedl nějakou úpravu přesně podle daného postupu, když ten samý postup může spolehlivěji udělat automat.
Pokud by se reaktor dostal do nestandardního stavu, se kterým nikdo nepočítal, nebo který vyžaduje odstavení, samozřejmě se odstaví a nejprve se řeší příčina. Ale stejně tak služba, která se dostane do nestandardního stavu, se kterým nikdo nepočítal, nebo který vyžaduje zastavení, tak se znova nespouští. Ale ukončení procesu není nic nečekaného nebo překvapivého.

Přesně jako ti piloti se chová i správce služeb. Znovu spustí službu, a ta se podle dostupných informací pokusí obnovit plný běh, nebo se pokusí o co nejbezpečnější havarijní přistání. Jenže k tomu, aby cokoliv z toho mohla udělat, musí nejprve běžet. Ano ten příměr s letadlem nebyl úplně přesný – přesnější by bylo, kdyby v okamžiku, kdy dojde k problému, ty piloty někdo vyrazil z pilotní kabiny a dovolil jim vrátit se, až vyšetřovatelé budou mít bezpečně zjištěno, v čem byl problém.

"Nečeká se pokaždé na operátora, aby provedl nějakou úpravu přesně podle daného postupu, když ten samý postup může spolehlivěji udělat automat."

Správně, to je přesně to, co jsem psal u monitorovacícho systemu. Pokud nastala přesně definovaná situace, může monitorovací system spustit skript, který to dá dopořádku.

"Přesně jako ti piloti se chová i správce služeb."

To je trochu zmatení pojmů. Pilot v letadle je totéž co admin v IT. Operátor ve velíně jaderného reaktoru je totéž co admin v IT. Úkolem admina je to letadlo nebo ten reaktor bezpečně udržovat v bezpečném provozu. A pokud to nejde, tak bezpečně odstavit. Ano, slouží mu k tomu další nástroje. Pokud systemd (nebo správcu služeb) považuješ za totéž jako pilota v letadle, asi se nemáme o čem bavit, naše myšlení je úplně někde jinde.

To je ale krasny priklad. U te jaderky je nebezpecne pokracovat dal, na druhou stranu je sit navrzena na to, aby ji slo odstavit a tak ji odstavi a hledaji pricinu.
U letadla jaksi nejde presadit cestujici za letu do zalozniho letadla a tak se musi pokracovat v letu i kdyz to letadlo ma kritickou zavadu.

Stejne tak IT admin - nekdy musi za kazdou cenu prijit na pricinu a az pak nastartovat sluzbu, nekdy ji musi nastartovat rovnou a pricinu resit pozdeji, a nekdy ji proste jen nastartuje a nic neresi proste proto, ze to bud nikoho nezajima nebo to nikdo nezaplati. To je proste realita. Jsou firmy, kde by zkoumaveho admina vyhodili, protoze veci zbytecne komplikuje.

Pokud je to dron (na behu sluzby vetsinou nezavisi lidske zivoty), tak muzou byt situace, kdy je proste nejjednodussi/nej­levnejsi/nejrychlej­si to poslat znova do vzduchu. Proste jsou takove.

Pořád tedy píšete o tom, jak vypadá správná unixová služba. Podle vás tedy správná unixová služba bez řečí nastartuje s poškozenými daty a tiše je dál ničí? Tak to máme diametrálně odlišnou představu o tom, jak má vypadat dobrý software.

Podle mne to „dá do pořádku“ nemá dělat nějaký skript, ale má to dělat ta služba samotná. A nevidím důvod, proč čekat na pokyn monitorovacího systému (který navíc netuší nic o situaci), když to správce služby zjistí okamžitě. Třeba pokud se služba plánovaně restartuje (třeba po upgradu), nebyl bych nadšen z toho, že se do toho začne montovat nějaký zachraňovací skript.
Podle mne úkolem admina nebo operátora v jaderné elektrárně je řešit nestandardní situace. Bezpečné rutinní udržování v bezpečném provozu je věc, která jde daleko lépe automatům než lidem.
Jinak to, že úkolem admina je, aby služby bezpečně běžely, tady píšu stále dokola. A neustále se dozvídám, že start služby je velmi kritická operace, kterou musí provést jedině administrátor ručně až po té, co zkontroloval vše možné i nemožné.

"Třeba pokud se služba plánovaně restartuje (třeba po upgradu), nebyl bych nadšen z toho, že se do toho začne montovat nějaký zachraňovací skript."

Když admin dělá update, tak snad dá něco jako downtime do monitorovadla. Nebo ve tvém světě se služby sami updatují a sami poté restartují? To mi opět připomíná widle, kde se každá appka stará o svou vlastní aktualizaci. V linuxu máme repositáře. Služba se (sama sebe) neupdatuje.

"start služby je velmi kritická operace"

Nějak ti tam záměrně vypadlo několik slov. Start služby po předchozím neočekáváném pádu je velmi kritická operace.

Downtime v monitorovadlu je dobrý způsob, jak se o příští chybě dovědět rovnou od uživatelů (a pak zjistit, že tenkrát to monitorovadlo někdo zapomněl zase nahodit).

Nic mi tam nevypadlo. Ta služba neví, zda startuje po předchozím neočekávaném pádu. Takže nemůže nikdy nastartovat automaticky (ani po startu počítače), musí vždy administrátor potvrdit, že se nejedná o situaci po předchozím neočekáváném pádu a službu nastartovat ručně.

Také by mě zajímalo, co tak magického dělá administrátor před tím spuštěním služby - že to nemůže udělat ta služba sama.

A jak je to s tou službou souborových systémů? Opravdu při startu žádný souborový systém nepřipojuješ automaticky, ale nejprve je nějak kontroluješ a teprve pak je připojíš ručně? Nebo jsou souborové systémy nějaký magický druh služby, která zvládá ten automatický start, kontrolu, že služba může běžet, a podle výsledku kontroly buď plný provoz služby (připojení disku) nebo její ukončení s chybou?

Zacina to byt dost napinavy. Ono vlastne v principu jakekoli nestandardni/ne­ocekavane chovani jakehokoli programu je chyba a mohla by vest k poskozeni dat apod. To ze to nespadlo jeste neznamena, ze je vse ok! V takovem pripade by melo monitorovadlo prepnout vsechny FS do readonly, povypinat vsechny demony, odhlasit vsechny usery, prepnout kernel do trasovaciho rezimu a zavolat admina. Admin se dostavi, zkusenym okem omrkne vsech 50TB dat a s pocitem bezpeci nahodi demony zpet. Je to tak spravne zodpovedne (TM)?

"Downtime v monitorovadlu je dobrý způsob, jak se o příští chybě dovědět rovnou od uživatelů (a pak zjistit, že tenkrát to monitorovadlo někdo zapomněl zase nahodit)."

Pro ty, kteří nikdy neviděli například nagios (nebo icingu), tak dowtime se dává na určitý časový interval. Default je 2h, lze jej zkrátit nebo prodloužit. Pokud vím, že update bude trvat deset minut a nahlášená doba výpadky služby je 20minut, dám downtime na 15minut. Jak prosté.

"Také by mě zajímalo, co tak magického dělá administrátor před tím spuštěním služby - že to nemůže udělat ta služba sama."

Tak opět, po stošedesáté. Bavíme se celou dobu o situaci, kdy ta služba, nebo rovnou celý server přestal fungovat v důsledku nějaké nestandardní situace. Služba spadla, vypadl proud, do serveru natekla voda. Je to mimořádný stav. Ještě jednou speciálně pro tebe. Jedná se o mimořádný stav, když služba nebo server, který má běžet, náhle něbeží. Doufám že už je to konečně jasné.

Tuto skutečnost admin ví. A když tuto skutečnost admin ví, tak podle závažnosti situace se rozhodne co dál. Buď si "jen" pohlidá start služeb. Je to start po nějaké předchozí nestandardní události, která (opět pro jistotu opakuji) vedla k pádu služby či vypnutí celého serveru. Nebo udělá nějaká další opatření. Jako třeba že server vysuší. Není to nic magického, ale je to na zvážení admina, co a jak provede. Od toho tam je.

"A jak je to s tou službou souborových systémů? Opravdu při startu žádný souborový systém nepřipojuješ automaticky, ale nejprve je nějak kontroluješ a teprve pak je připojíš ručně?"

Tohle se snad děje automaticky při každém připojení fs. Jestli narážíš na /boot, který se rovnou čte, protože v MBM a prvních sektorech není místo na kompletní fsck, tak /boot je zvykem připojovat jako readonly, protože je to oddíl, do kterého se běžně nezapisuje. Pouze při změně jádra či nastavení. Riziko, že se takový oddíl poškodí je minimalizované a de facto omezené pouze na chybu hw. /boot je tak jediným oddílem, který se rovnou čte, protože tak, jak je udělán bootovací proces PC, to nelze dělat jinak.

Veškeré další připojované systémy se v klasickém init skriptu nejdříve zkontrolují (fsck) a až potom se připojí. Dokonce je na to sloupec i ve fstabu (pořadí, ve kterém se mají kontrolovat).

Takže ne, já systémy souborů nekontroluji, kontroluje to při _každém_ bootu samotný os.

To mi ale nebrání v tom, pokud usoudím, že to vypnutí bylo hodně nestandardní (například odešel diskový řadič), udělat ten check z nějakého jiného prostředí (systemrescuecd apod.). Opět je to na rozhodutí admina.

V čem je připojení souborového systému tak ojedinělé, že tam může zotavení z předchozího neznámého stavu a vysušení proběhnout automaticky, ale u žádných jiných služeb to možné není? Proč nemůžu mít nějakou jinou službu, která se bude chovat stejně jako připojení souborového systému - tj. na začátku se provede kontrola, a teprve pokud dopadne dobře, naběhne ta skutečná služba? A stejně jako u souborového systému by pak podmínky pro běh té služby nekontroloval administrátor, ale kontrolovaly by se při _každém_ spuštění té služby samotnou službou?

Pokud se admin rozhodne, že předchozí závada nebyla tak závažná a server spustí, tak to také může dopadnout tak, že fs check při startu os mu sdělí, že ten fs je bez dalšího zásahu automaticky neopravitelný. Což se ostatně stává i u relativně bezpečného odpojení od elektřiny. A potom je opět na adminovi, co udělá. Buď prosté fsck -yf a jede se dál, nebo zvolí opatrnější metodu a udělá si třeba kopii daného blokového zařízení a nad mí bude bádat co dál.

Proto ten admin u startu po zotavení z nějaké chyby stejně musí být, protože pravděpodobnost nutnosti jeho zásahu je vyšší (dle závažnosti předchozího problému), než u startu po korektním vypnutí (kde je pravděpodobnost zásahu prakticky nulová a pokud je potřeba, tak naopak ukazuje na opravdu velký problém bez předem známé příčiny -- protože po korektním umount se na daném blokovém zařízení nemá co měnit).

Takže ne, ono "vysušení" neproběhlo automaticky jak se snažíš podsouvat, ale admin se rozhodl, že to prostě spustí s vědomím toho, že fs check to zkontroluje.

Ale jako to už se fakt točíme v kruhu, vše podstatné bylo řečeno. Jen neustále vytrháváš věci z kontextu, zasazuješ do jiných, úmyslně zapomínáš na části podmínek apod.

Jestli ve tvém adminování to funguje tak, že se věci startují automaticky bez ohledu na předchozí stav, tak fajn, je to tvůj boj. Moje a z diskuse plyne, že nejen moje praxe je taková, že je potřeba si dát velký pozor na to, jak dobře ta služba najede po předchozí neočekávané události. Ano, jsou služby, které si žádný stav neuchovávají a krom konfiguračního souboru (pokud jej mají) nemají žádná persistentní data. Tyto služby nemají co kontrolovat a je možné je spustit. Ale o těchto službách se nebavíme.

Ten FS je naprosto konkrétní případ "služby" na které závisí prakticky všechno ostatní. A o tento typ služeb se admin musí sakra dobře postarat, protože pokud bude fs obsahovat vadná data, tak je všechno na ním v poškozené. Toto nevyřeší žádný init, dokonce to často nevyřeší daný konkrétní admin. Proto je i tolik dotazů v poradnách jak postupovat a proto je jako první rada udělat si kopii na úrovni blokového zařízení.

Tímto tuto diskusi končím, vše podstatné bylo řečeno a mé stanovisko je jasné. Očekávám, že opět vytrhneš něco z kontextu, klidně si posluž.

Takže jsme se snad shodli na tom, že existují služby (například souborový systém), které si svůj stav dokážou zkontrolovat samy, a mohu to dělat při každém startu. Případně se mohou z některých typů problémů i samy zotavit. Ty služby je tedy možné bezpečně startovat bez ohledu na předchozí stav, protože ta služba si při startu předchozí stav zjistí. Takže nic nebrání tomu, aby taková služba startovala zcela automaticky, bez zásahu admina – a admina zavolá teprve tehdy, když je o problém, se kterým se ta služba neumí nebo nechce automaticky vypořádat.
Ty takhle provozuješ jedinou službu – souborový systém, někdo jiný takhle provozuje i jiné služby, které splňují výše uvedené podmínky.
Já osobně považuju služby, které si ten stav zkontrolovat neumí, za nedodělky. K nějaké chybě může dojít i bez toho, aniž by se to projevilo nějak navenek. Takže služba by neměla být závislá na tom, že admin chybu dostatečně rychle odhalí a službu zastaví (nebo služba stihne spadnout sama), ale měla by být schopná ty anomálie detekovat sama. V souborových systémech je to běžné, u databázových systémů také.

Když nikdo nezajistí, že kontrola integrity bude dostatečná, jak zajistí dostatečnou kontrolu správce? Tady se to pořád řeší, jako kdyby měl správce nějaké magické schopnosti. Ne, ten správce taky jen spustí nástroj na kontrolu integrity dat, a když ten nástroj prohlásí, že je vše v pořádku, tak tu službu spustí.

Ano, správce má rozum a může něco zjišťovat, ale k té chybě klidně může dojít, aniž by ta služba spadla. Takže tu máme stejný problém, ale správce nedostane žádný podnět – takže asi stejně nezbývá, než aby se s tím nekorektním stavem uměla ta služba sama vyrovnat, a alespoň se ukončila.
Také pořád nevím, proč by se měl správce nějak zachovat až po té, co podrobně prozkoumá příčinu. Třeba pokud dojde při připojování souborového systému k chybě, kterou je možné opravit, chyba se opraví a souborový systém se přimountuje – a přesnou příčinu je možné zkoumat potom.

Vaším argumentem proti restartu služeb přece je, že může dojít k problému a ta běžící služba bude problém dále zhoršovat. Tak mně jenom připadá, že k tomu problému může dojít kdykoli, restart služby není žádný speciální případ. Takže pokud ten problém chcete nějak řešit, musíte ho vyřešit obecně (nejspíš tak, že ta služba konzistenci dat kontroluje průběžně). No a pak už zase nemusíte řešit nějaké ruční zásahy administrátora do restartu služby.
Souborový systém je příklad služby, připojování souborového systému je příklad startu služby. A je to přesně ten případ, kdy administrátor nemá žádné magické schopnosti, nebude kontrolovat disk v hexaeditoru nebo pod mikroskopem, ale spustí fsck. Spuštění fsck ale není žádná věda a zvládne to automat.

"A je to přesně ten případ, kdy administrátor nemá žádné magické schopnosti"

Ale má. Pro někoho magické, pro někoho zcela všední. Má mozek, má zkušenosti, má znalosti. Spuštění fsck může v úrčitých situacích udělat víc škody než užitku. Někdy i samotné zapnutí onoho disku není nejlepší nápad. (Znám případ, kdy disk fyzicky někomu vypadl z ruky, "něco v něm hrkalo" a dotyčný neměl žádný lepší nápad, než to prostě zapojit a nechat roztočit plotny. Pokud se z toho dalo před tím něco dostat, tak po této akci už v žádné případě.)

Ten disk, který někomu vypadl z ruky, byl zároveň v běžícím serveru? Nebo jak se to přihodí, že disk někomu vypadne z ruky, a pak se najednou ocitne v prostředí, kde má být připojen? Já bych si myslel, že když má někdo disk v ruce, má i možnost rozhodovat o tom, zda a jak ho někde nastartuje.

"Já bych si myslel, že když má někdo disk v ruce, má i možnost rozhodovat o tom, zda a jak ho někde nastartuje."

Stejně jako admin má možnost po neočekávaném výpadku se rozhodnout, jak bude dál postupovat. Zapnutím serveru počínaje, přes obyčejný restart služby až po podrobnou diagnostiku (hw nebo dat). Je to zcela na adminovi. Ty bys to prostě nechal na automatice s tím, že když např. fsck neprojde, tak se to nenamountuje. Jenže v té chvíli už mohou být data nenávratně ztracena. Ta automatika nemá žádnou možnost zjistit, zda to, co se chystá udělat, v daném konkrétním případě situaci ještě nezhorší. Proto je to zcela na adminovi.

Rozdíl je v tom, že do stavu "disk v ruce" se nelze žádným způsobem dostat bez zásahu administrátora. Když už do toho administrátor zasáhne (vypne server a vezme disk do ruky), je logické, že to pak zase musí vrátit do provozuschopného stavu. Ukončení procesu je ale jiný případ, to není zásah administrátora. To s "chystá se udělat" ale úplně stejně platí i pro "právě dělá". Pokud něco pokazí start služby, úplně stejně se to může pokazit i tehdy, když ta služba nespadne a poběží dál. Takže řešit zrovna ukončení procesu jako zvláštní případ nemá smysl - spíš je potřeba zabezpečit, aby ta služba rozpoznala, že je něco špatně, a alespoň neničila data. Samozřejmě, pokud je nějaká služba známá tím, že poničí data a spadne, a po restartu to není schopná poznat, a někdo je nucen takovou službu provozovat, nezbývá mu než si užívat manuální obnovy dat a modlit se, aby to příště zase dal dohromady. Ale to už se dostáváme k oblíbenému tématu, zda by dotyčný raději nechtěl rovnou používat Windows.

"Pokud něco pokazí start služby, úplně stejně se to může pokazit i tehdy, když ta služba nespadne a poběží dál. Takže řešit zrovna ukončení procesu jako zvláštní případ nemá smysl - spíš je potřeba zabezpečit, aby ta služba rozpoznala, že je něco špatně, a alespoň neničila data."

Nejde jen o ono pokažení startu, jde o důvod, proč ta služba spadla (doufám že se stále ještě bavíme o situaci, kdy dojde k neočekávanému ukončení služby či běhu servery). Bud se sama dostala do takových podmínek, že není možné její další běh, nebo ji něco z vnějšku odstřelilo. V každém případě to má hodně daleko do standardních běhových podmínek (programy běžně nepadají a běžně je nic neodstřeluje), proto je nutné v případě nestandardního ukončení služby zjistit důvod jejího ukončení, tento odstranit a potom tu službu znovu spustit.

Pokud bude na serveru docházek paměť, OOMK bude zoufale střílet, tak opakovaný restart odstřelené služby opravdu situaci nezachrání. Pokud do serveru natekla voda, není dobrý nápad ho zapínat. Ale příkladů jako tento bylo již uvedeno dost.

Jenže důvod, proč ta služba spadla, může úplně stejně nastat i v jiném případě, kdy to tu službu neshodí. Takže není moc rozumné čekat, jestli se o tom problému náhodou dozvím tak, že služba spadne, ale měl bych ten problém detekovat nějak jinak. U té vody se také používají detektory a nečeká se na to, až voda nateče do serveru a zkratuje jej, a teprve pak to někdo začne řešit.
Pokud OOMK odstřelí nevinnou službu, situaci nijak nepomůže, když ta služba zůstane zastavená. Pokud odstřelí tu správnou, je to buď krátce po startu a bude k tomu docházet opakovaně, pokud to bude hodně rychlé, správce služeb službu odstaví rovnou sám. A nebo ji zastaví správce, který ji před chvílí zapnul. A nebo to bude třeba po několika dnech nebo měsících běhu, a pak je pravděpodobné, že se ten problém neobjeví hned po restartu znova, ale služba může klidně běžet dál, a mezi tím se bude zkoumat, proč k problému došlo.

Jsem jenom hloupy programator, ale treba vam to dokazu vysvetlit. Z principu muze jakakoli akce pokazit jakakoli data na danem systemu. Muze to byt akce ktera skoncila uspesne, muze to byt nestandardni chovani, muze to byt pad, hw chyba, vypadek proudu. Z tohoto hlediska neni rozdil mezi runtime pameti v kernelu, FS na disku, daty v DB. Neni rozdil, jestli sluzba spadla nebo spatne naparsovala konfigurak nebo pracuje zdanlive spravne. Cokoli muze vest k poskozeni dat.

Dale, z principu neni mozne 100% odhalit poskozeni dat.

Pak jsou zde komponenty jako treba zurnalovaci FS, ktere se snazi zajistit nejakou miru spolehlivosti bez zasahu admina a takove, ktere se o to nesnazi, nicmene v principu je mozne napsat jakoukoli sluzbu tak, aby se o sva data starala stejne jako zurnalovaci FS (treba).

Ale porad jsou zde admini (jako treba vy), kteri si z toho nepreberneho mnozstvi zpusobu jak se muze neco pokazit, vybrali pouze sluzby a pouze jejich pad a rozhodli, ze tohle musi resit oni rozumem. Ostatni udalosti je patrne nechavaji klidnymi. Nevim jestli zijete v blahe nevedomosti, ze vase data jsou ok zatimco se nedivate, ze kontrola konzistence je nejak magicka, ze kdyz dopadne dobre, tak se muze sluzba nahodit atd. Ten pocit je velmi falesny. Stejne nakonec jen delate nejake automaticke kroky a doufate, ze to bude ok. Stejne tak to muze delat automat. Ostatne, v oblastech kde o neco jde jsou definovany standard operating procedures a pro lidsky rozum se tam moc mista nenechava.

Na druhou stranu tu mame treba google se svymi datacentry, kde to proste resi uplne jinak a rozhodne tam nebehaji admini ke spadlym serverum.

"Na druhou stranu tu mame treba google se svymi datacentry, kde to proste resi uplne jinak a rozhodne tam nebehaji admini ke spadlym serverum."

Takže počet běžících serverů v čase neustále ubývá, protože k těm spadlým přece nikdo neběhá.

Víte o tom, že jsou místa, kde je jen výměna vadných disků full time job?

> Mně něco takového hlásat aspirant na pozaci admina, tak se s ním ani dál nebavím.

V prvni rade by se mel admin (a stejne kazdej dalsi aspirant na praci v IT) ptat, jakej je na to rozpocet, co se od toho ocekava a jaky k tomu budou dalsi podminky. Bez toho nemuze rozhodnout reseni. Takovi, co kvuli kusu plechu zacnou stavbou ocelarny jsou mnohem vic nepouzitelni nez admin, co necha restartovat sluzbu. Vzdy zalezi na tech ostatnich podminkach.

Je zajimavy, ze v teto diskuzi nikdo nerekl, ze zalezi na tech okolnostech, ale reseni uz ma jasny.

Vy tomu rikate ze dlabou, ja rikam, ze pouzivaji nejlepsi reseni vhodne pro dany ucel. Jestlize totiz udrzba serveru ktery automaticky restartuje nestoji ani korunu a udrzba adminem stoji desetitisice nebo statisice behem let a vysledny efekt je nerozeznatelny, tak proc by platili toho admina, ze. Pokud je pravdepodobnost, ze dojde k poskozeni dat a nutnosti obnovy ze zalohy nizka (behem tech let to nikdy nenastalo) a pripadne skody zanedbatelne, tak firma prave usetrila stovky tisic korun za administraci. V tom svetle se da i chapat, ze se nekterym adminum takovy pristup nelibi :-)

> V tom svetle se da i chapat, ze se nekterym adminum takovy pristup nelibi :-)

To, co sa nam nepaci je, ked sa potom firma s takymto pristupom pyta, kde ze sa jej podeli vsetky data. Pretoze aj ked je vsetko zmluvne osetrene a admin moze odkracat s hlaskou "varoval som vas", stale je to z ludskeho hladiska maximalne neprijemna situacia.

Neadminoval v těch firmách náhodou někdo, kdo tvrdil, že k poškození dat může dojít jedině pádem aplikace, a že dobré aplikace nepadají, takže vlastně není čeho se bát?

Nepravdepodobne.

Dost ma pobavilo, ako ste vy dvaja s Karllom odrazu svorne zacali hlasat nieco v zmysle "pad sluzby nieje jediny sposob, ako poskodit data a vy sa tu starate vyhradne a len o ten." A vcelku by ma zaujimalo, z coho ste obaja nezavysle na sebe taku sprostost vydedukovali :)

Treba takovy Seti pred dvema hodinami:

>Já tady mluvím o restartu služeb a vy si vymýšlíte nějaké problémy na pozadí nebo mountování filesystému

Z toho jsem si dovolil vydedukovat, ze Seti rozlisuje restart sluzby a mount systemu, ale z principu muze oboji data rozbit nebo neprijit na to, ze rozbita jsou apod.

> Pochopitelně, že automatický restart služby po jejím pádu a mount FS je něco jiného

Tak mi prosimvas vysvetlete, v cem je to v principu jine. Obecne k poskozeni dat muze dojit uplne kdykoli a jakkoli - chybou v programu, vypadkem site, vypadkem spojeni s jinou sluzbou, proste obecne jakkoli. Jediny zpusob jak se s tim aspon nejak vyporadat je, ze se program aktivne snazi o nejakou zaruku konzistence dat a jeste lepsim zpusobem jsou inkrementalni zalohy. Takze muzete paralelne spustit vice stejnych systemu a volit spravne vysledky apod. Z toho taky neprimo plyne, ze pokud se sluzba aktivne snazi o konzistenci a take si spusti kontrolu dat pri startu, tak vy stejne o moc vic neudelate - tim se dostavame k dalsi otazce, ktera tu uz mnohokrat padla - proc se tohle nemuze udelat automaticky?

Ve skutecnosti k situaci ekvivalentni "restartu sluzby" muze dochazet uvnitr programu docela casto, ale protoze se to nevypise do zadneho logu, tak jste uplne v klidu. Ale kdyz to v tom logu je, tak to najednou pusobi strasne dulezite.

Dale podotykam, ze ten samotny pad bezi na uplne stejnem CPU a se stejnou RAM a stejnym ulozistem, je to porad ten samy turingovsky uplny system. Nejlepe bude, kdyz vysvetlite, ktere strojove instrukce bezi behem padu sluzby, ktere nikdy jindy bezet nemuzou, a ktere strojove instrukce spoustite vy pri manualnim restartu, ze je nemozne je pustit automaticky. Verim ze pak se posuneme v debate dale :-)

Pořád nechápu, v čem je ten rozdíl. První případ: dojde k neočekávané chybě, služba začne poškozovat data, ale běží dál. Druhý případ: dojde k neočekávané chybě, služba spadne a po opětovném spuštění by začala poškozovat data. Podle vás první případ je OK a admin nemusí nic řešit, a druhým případem se admin musí zabývat? Mně tedy připadá, že je jedno, jak přesně se ta chyba projeví. A že tedy poškozování dat službou je nutné řešit vždy, bez ohledu na to, zda služba spadla nebo nespadla.

Plyne to z vašich tvrzení. Nebo snad ne? Stačí si odpovědět na pár jednoduchých otázek. Pokud se služba dostane do stavu, kdy je její další běh nežádoucí (např. začne ničit data), má se o tom administrátor dozvědět vždy/někdy/nikdy? To, že se služba dostala do takovéhoto stavu se projeví pádem služby vždy/někdy/nikdy? Z předchozích tvrzení tedy plyne, že pád služby je z hlediska detekce chyb situace specifická ničím / vůbec ničím?

V čem je ten automatický restart služeb tak jiný? Buď ta služba bude po startu normálně fungovat, pak je to v pořádku a v automatickém restartu nebyl žádný problém. Nebo ta služba nebude normálně fungovat a v nejhorším případě bude situaci zhoršovat – např. bude ničit data. Jaký je rozdíl v tom, když se ta služba takhle začne chovat po automatickém restartu, a když se tak začne chovat za normálního běhu? Podle mne žádný, je tedy nutné tomu předcházet neustále – no a pokud už mám zaručeno, že služba rozpozná situaci, kdy by se stav jenom zhoršoval, a vypne se nebo se přepne do nějakého bezpečného režimu, může se klidně služba automaticky nastartovat.
Takže celé „řešení“ „hlavně ne automatický restart“ je jenom jinak nazvaný přístup: „Zuřivě se modlím, aby služba spadla co nejdřív po té, co začne zhoršovat situaci – např. poškozovat data. Protože jestli nespadne, nijak to nepoznám a dozvím se o tom teprve až budou všechna data pryč.“

"Pane, co tady tak chodíte? - Ale, ztratil jsem klíče. - Tak já vám pomůžu je hledat... Pořád nic, opravdu jste je ztratil tady pod lampou? - Ne, támhle o kus dál ve tmě, ale copak tam je můžu najít?"
Takhle nějak je to i s tím správcem? Chyby, které se projeví pádem služby, se dobře hledají, tak budeme hledat jenom ty? Já právě neřeším následek - zničená data - ale řeším to, jak tomu zničení předejít. Přičemž tím "předejít" myslím skutečně předejít ničení dat, ne čekat, až to dojde tak daleko, že služba havaruje.
Takže nejde o dva odlišné případy. Je to pořád jedna a táž chyba, a je víceméně věcí náhody, jestli zároveň způsobí pád programu nebo ne. Takže se musím snažit té chybě předcházet, bez ohledu na to, zda službu shodí. Ale máte pravdu, že tohle je spíš věc programátora, administrátor si akorát může (někdy) vybírat, zda zvolí službu, která se takhle chová, nebo službu, která data klidně nenápadně poškozuje.
Pak asi nezbývá než odpovědět v tradici této diskuse, že takoví administrátoři ať pak radši zůstanou u Windows, kde je zvykem, že služba pokazí co může a na závěr slavnostně spadne. Já zůstanu věren tradici unixových systémů, kde se administrátor nemusí bát nějakou službu nastartovat.

To ze jste nepochopil argument jeste neznamena, ze je kolega mimon.

A jako vzdy je paralela mezi softem a dopravnimi prostredky tezce zavadejici...

Kde se v mém pojetí objevuje nějaké „posbírá a sestaví“? V mém pojetí je potřeba se o závadě na letadle dozvědět co nejdřív, není potřeba čekat, až letadlo spadne. Ale dozvídám se tu, že někteří raději praktikují postup „Zatím to nespadlo, tak je všechno v pořádku. Až se objeví nějaké problémy, poznáme to, protože to spadne.“

> NEEXISTUJE ani jedina sluzba, kterou by normalni admin restartoval jen proto ... aby bezela

V tom pripade mam protiargument ze zivota, tedy vase predpoklady jsou mylne, vasimi slovy: "Picoviny tu taras ty".

Nikdy po me zadny penize nechteli protoze nevznikla zadna skoda.

Mam cim dal vetsi pocit, ze to tady je samy teoretik a akademik, ktery hlasa tu spravnou pravdu, jak ma admin nahazovat systemy a resit konzistenci dat (patrne s hex editorem nebo cim).

Nikdo ale nemluvi o terminech, nikdo nemluvi o penezich, to je nejakej paralelni vesmir nebo co. Bud delate pro stat, kde se prachy neresi, nebo to jsou ohromny korporace kde minuta vypadku stoji miliony atd, nebo ja uz nevim.

Musim vam teda prozradit, ze existuje jeste zbytek sveta, kde uplne staci, kdyz to nejak bezi, funguje to, kde nikdo nezaplati admina na 24/7, kde nevadi kdyz by to pripadne chvili nebezelo, nevznikne tim milionova skoda a nikdo se nebude logovat na server v pet hodin rano. Chapete to? Mnohem dulezitejsi bylo, ze to bylo docela zadarmo a ze to proste _plnilo ucel_.

Onehda byl na TheDailyWTF clanek o tom, jak korporace nahazovala ohromny system, meli na to sileny mainframy, 3x zalohovany, ohromny datovy sklady, aby zvladli ten veliky provoz. Pak slavnostne sluzbu spustili a behem prvniho mesice meli celych 300 registrovanych useru. A podobne jevy vidim nejmin v polovine teto diskuze.

U trikolky a svyho decka asi ano. Ale co ten server? Budete to delat i zadarmo? Date kolegum svuj telefon, aby vas mohli otravovat kdykoli to padne, at uz jste na dovoleny nebo kdekoli, i kdyz vam to nikdo nezaplati?

Ona je ta posloupnost trochu jiná. Autorestart je jednou z vlastností, kterou spousta adminů chce – proto za ta léta vznikla spousta projektů, které tohle řeší. A lepilo se to k původnímu initu – samotný SysVinit už se dávno nepoužívá, snad všude je k němu dobastlené nějaké init.rc, no a nad tím bývá třetí vrstva, která řeší třeba ten autorestart, vedle toho ve třetí vrstvě může být třeba xinetd, a nejspíš i další věci. Teď se akorát někdo rozhodl, že místo tohohle bastlu na bastlu, který jen tak tak drží pohromadě^*), napíše něco nového, co bude splňovat současné požadavky. Protože jak se ukázalo, je to nesrovnatelně jednodušší, než něco dopisovat do toho bastlu. Což není nic proti SysVinit, vydržel s námi hodně dlouho, ale dneska už holt nestačí. (A některým ještě nějakou dobu stačit bude, než je to udržování tradice za cenu značného nepohodlí přestane bavit.)
Třeba já jsem se o tyhle init/rc války dlouho nestaral. Řešil jsem si, jak nad init+rc dostat daemontools (a měl jsem takový divný pocit, že se vlastně všechny tři části snaží dělat to samé, akorát každá neumí něco jiného – a že by ideální bylo mít to vše v jednom). A pak jsem si přečetl pár nenávistných blogů a komentářů o systemd (asi jako ten článek, pod kterým diskutujeme), a dozvěděl jsem se, že systemd ó hrůza udržuje spuštěné ty služby, které spuštěné mají být, navíc ještě hlídá stav služeb, troufá si přijímat notifikace, kdy služba doopravdy nastartovala a podle toho spouštět závislosti, připravit socket a službu spustit teprve tehdy, když se na něj někdo připojí (to taky nikdo nechce, proto existuje xinetd)… Byly to přesně ty věci, u kterých mi pořád vadilo, že to init/rc neumí, a divil jsem se, že to nechybí všem. Takže tímto děkuji všem systemd haterům, kteří mi ukázali, že to, co už léta marně sháním, konečně někdo dělá.

*) Ano, nastartovat služby to většinou s vypětím všech sil zvládne, ale nesmíte po tom chtít nic jiného. Jenom si vzpomeňte, kolik let se řeší paralelní start – a stále je to všude v různých experimentálních fázích, nikde to není tak, že se to rutinně používá a nikdo se tomu nediví. Přitom je to vlastně úplně triviální věc.

Sice jsem říkal, že se další diskuse nebudu účastnit, ale tak když je ten pátek...

"Autorestart je jednou z vlastností, kterou spousta adminů chce"

Netuším, kde to bylo, ale snad v nějaké specifikaci programovacího jazyka bylo uvedeno, že pokud se vám nějaká konstrukce nebo použití zdá přiliš složitá, tak se zamyslete, zda věci děláte správně. Protože, jak autoři uváděli, existuje i jiná, jednodušší cesta. To, že je to složité je indikátor toho, že jdete špatně.

Stejně tak API jisté databáze exportuje pouze a jen metody s konstatní časovou složitostí. A opět zcela záměrně s nadějí, že programátor místo toho, aby implementoval cosi se složitostí O(e^n) se zastaví a zamyslí, zda nemůže použít výhody dané DB, data uspořádat jinak, a opět to mít jako O(1). Nebo třeba zjistí, že udělal chybu v návrhu a daná DB se na jeho problém vůbec nehodí.

Tedy to, že něco chci a ono to tam (za 40 let) není, by mělo být upozorněním, že to možná jde dělat jinak a že ono zvolené řešení asi nebude to nejlepší. Je to ona pokora o které jsem tu psal.

"ale dneska už holt nestačí"

Na co dneska nestačí? Co se změnilo? Proč se to změnilo? A je to správně?

"kolik let se řeší paralelní start"

A pokaždé je pod tím diskuse: je sice pěkné, že to startuje 5s místo 10s, ale ono je to stejně jedno, protože jen POST trvá na domácím hw 30s (a na serveru klidně i 10minut) a ten boot jednou denně (jednou za rok), klidně počkám. On se totiž rychlejší start dobře vyjímá na "letácích", ale užitek pro od jisté hodnoty nemá (5s místo 10s je zrychlení o 100%, což zní bombasticky, no ale když se napíše zrychlení o 5s, tak už to tak dobře nevypadá -- totéž marketingové kecy u různých "green" technologií. Úspora stovky procent!!! Jo, místo 200mW to má teď 50mW za dvojnásobnou cenu a hlavně dalšího odpadu. To je hrozně ekologické.). Nehledě na to, že paralelní start u klasických disků start spíše zpomaluje (mě na ssd -- iops asi tak 40tis -- a systemd userspace startuje 1.3s, ale klasický disk má iops kolem 100 a je mnohem výhodnější ho používat sekvenčně).

"Takže tímto děkuji všem systemd haterům, kteří mi ukázali, že to, co už léta marně sháním, konečně někdo dělá."

No rádo se stalo, ale to jsi nemusel čekat léta a mohl jsi ty Widle používat rovnou.

To, že je to složité je indikátor toho, že jdete špatně.
Když je něco složité (init+xinetd+spou­sta různých bash skriptů) a indikuje to, že jdeme špatně - není na čase pokusit se najít tu správnou cestu?

Tedy to, že něco chci a ono to tam (za 40 let) není, by mělo být upozorněním, že to možná jde dělat jinak a že ono zvolené řešení asi nebude to nejlepší. Je to ona pokora o které jsem tu psal.
A když to někdo pečlivě zváží, a přijde na to, že je chyba opravdu v tom 40 let starém systému, může to opravit? Není pokora také v tom nepodezírat hned každého, že to nepromyslel? Není pokora také v tom, i když to sám promyslíte a na nic lepšího nepřijdete, připustit, že ten druhý se nad tím možná zamyslel lépe a na něco přišel?

Na co dneska nestačí? Co se změnilo? Proč se to změnilo? A je to správně?
Na co dneska nestačí? Tak evidentně SysVinit nestačí ani na zavedení systému, když se k tomu musí dobastlovat nejrůznější shell skripty. Změnilo se třeba to, že mnohem méně chceme říkat jak se něco má udělat na nejnižší úrovni, ale raději říkám, co se má udělat. Tedy ne že se má nastartovat databázová služba a po ní web server, ale řekneme, že chceme, aby běžel web server. Ono je to jak pořád stejné, a je lepší to popsat jednou a pak už to jen používat, než to vymýšlet pořád znova.

je sice pěkné, že to startuje 5s místo 10s, ale ono je to stejně jedno,
Možná je to prkotina, ale každopádně to znamená, že SysVinit není nejlepší možné řešení. Tady vůbec nejde o to, jestli paralelní start něco ušetří. Ty problémy s paralelním startem jsou především indikátorem toho, že je v tom systému něco hodně špatně, a je to tím systémem celé prolezlé.

No rádo se stalo, ale to jsi nemusel čekat léta a mohl jsi ty Widle používat rovnou.
Já ale nechci používat Windows. Nevím, proč bych nemohl používat linux způsobem, jak chci já. Je mi líto, že někomu bořím jeho představu o 40leté tradici, já mám tradice taky rád, ale když je něco podle všeho hloupá tradice, tak se jí vzdám. Takové linuxové jádro taky mělo spoustu let tradičně BKL, taky to léta stačilo, taky se jeho odstraněním prakticky nic neušetřilo, ale prostě to byla přítěž, i když to v době vzniku bylo nejlepší možné řešení.

"Když je něco složité (init+xinetd+spou­sta různých bash skriptů)"

xinetd považuji za špatný nápad a sám ho ve svých systémech nepoužívám.

Spoustu různých bash skriptů považuji za dobrý nápad, protože typickým použitím bashe je pouhé spojení vstupů a výstupů několika málo programů. Bash je pouze takové tkanivo, pomocí něhož se staví na již hotových komponentách.

Většinu těch komponent použitých v "klasických" init bash skriptech stejně admin zná a používá je i k jiným účelům. Na zjištění, které služby se startují v jakém pořadí mi poslouží příkaz ls nebo třeba komplexní program mc. Oba tyto programy mohu použít i k něčemu jinému. A typicky se právě používají k něčemu jinému a ne jen k výpisu pořadí startu služeb.

Logy si mohu prohlížet příkazem more, less, cat, nebo třeba mcedit. Opět, less, more nebo třeba cat neslouží pouze k tomu, aby se pomocí nic prohlížely logy. Jsou mnohem univerzálnější.

Editovat konfiguraci mohu pomocí nástrojů jako vim, emacs nebo třeba mcedit. Opět, tyto nástroje mi neslouží pouze pro konfiguraci initu, ale mohu s nimi editovat libovolný textový soubor nebo je mít nastavené jako komplexní programátorské prostředí.

Stejně tak pro takového admina není žádný problém si změnit jakýkoliv init skript. Je to jen bash a je to jen pospojování jemu známých nástrojů. Kterých není moc.

A tak dále.

Všechny tyto nástroje admin zná, denně je používá. Proto pro něj není žádnou překážkou něco nastavit změnou parametru v nějakém textovém souboru, proto pro něj není problém se podívat na obsah logů.

A patrně každý admin používá jiné nástroje. Někdo vim, někdo emacs, někdo nano, někdo třeba na grafickém terminálu sublime nebo kate. Ten systém nikoho nenutí používat nějaké konkrétní nástroje.

SystemD jde jinou cestou. Na prohlížení logů musím použít journalctl. Fajn, nemusím, pokud si nastavím přesměrování na syslog. Je to práce navíc a navíc musí běžet jakýsi démon. Proč to není naopak? Tedy, že journalctl by byl speciální program pro snadné čtení logů? Logy by byly v textových souborech jako dosud a pokud někdo chce použít journalctl, měl by tu možnost?

"A když to někdo pečlivě zváží"

Kdyby někdo pečlivě zvážil, projednal to v širokém plénu, napsal o tom rfc a nechal by ho schválit tak klidně. Nemám námitek. Potom by totiž mohlo vzniknout několik implementací tohoto standardu. A admin by si vybral, který chce, stejně jako například si vybírá FS (což může právě díky tomu, že všechny implementují stejný standard, což ovšem v žádném případě neznamená, že ty FS jsou stejné).

Zkušenosti s Lennartem jsou ale takové, že: rozbije, prosadí, nechá jinými opravit. Viz katastrofální zkušenosti s PulseAudiem, kdy se spousta věcí, co fungovala rozbila a potom se stav posunu o 20 let zpět. (S Alsou není problém samplerate 192kHz, PA až to určité verze měl problém s čímkoliv vyšším než s 44.1/48 defaultem. A to pouze na 16b. Návrat o 20let zpět. Ano, dneska už umí 96kHz/24b a lehce vyšší samplerate algoritmus, než je default. Fajn, už to není 20let, už je jen 5 let zpět.)

"připustit, že ten druhý se nad tím možná zamyslel lépe a na něco přišel?"

Nemám problém připustit, že se mýlím, nemám problém se zamyslet, že to někdo myslel lépe. Ještě jsem neviděl žádný příklad ze světa systemd, který by nebyl možný dřív. Není tam žádný přínos. Jen pokus o unifikaci. To za přínos nepovažuji.

"ale řekneme, že chceme, aby běžel web server. Ono je to jak pořád stejné, a je lepší to popsat jednou a pak už to jen používat, než to vymýšlet pořád znova."

Tohle jsem buď nepochopil já nebo ty. Já jsem si nevšiml, že by říkal, jak se to má stát. Prostě zadám: spusť db, spusť proxy, spusť webserver. Ať si to udělá jak chce. A můžu to "říct" stylem "pg_ctl start -D /data", "service postgresql start", nebo třeba "systemctl start pg.service". Je to úplně jedno, výsledek je stejný. Nevidím na tom nic k neustálému vymýšlení. On ten příkaz pg_ctl start -D /data stejně je ve všech případech někde ukrytý.

"Nevím, proč bych nemohl používat linux způsobem, jak chci já."

Klidně můžeš. Já vim, on, vi, ty pico. ;-) Každý má to své, co mu vyhovuje a co nejlépe odpovídá jeho problému, který tím řeší. Akorát nevím, proč jsem já a ostatní nucen používat zrovna systemd. Ono už to totiž není o tom, zda chci na linuxu používat systemd, to už je nutnost. Tato zrůdnost (podle mého názoru) prorostla do všech významných dister. Takže už to není GNU / Linux, už je to SystemD / Linux. Kdo nechce používat systemd, musí odejít pryč.

Toto je první věc za celou historii linuxu, kdy je něco nucené. Jinak si každý mohl používat fs jaký chtěl, editor jaký chtěl, shell jaký chtěl, webserver jaký chtěl. Se systemd to končí. Čím dál víc projektů na něm závisí.

Mě to nevadí ale mrzí. Já klidně přejdu na BSD, a život jde dál. Ale mrzí mě, že projekt, který vznikl z jisté filozofie FreeSoftware najednou končí takhle. Ale co, nic netrvá věčně, bylo to hezkých 12 let.

Problém je, že to tkanivo skriptů nedokáže kontrolovat stav služby. Dokáže ji jednorázově spustit, zastavit, zjistit stav. Ale nedokáže ji průběžně monitorovat, zjistit okamžitě, že skončila.
Abych zjistil, které služby se startují, tomu principiálně nic nebrání ani u Systemd (nevím, zda reálně nějaké symlinky vytváří, nikdy jsem takhle nepracoval se službami ani u jiných init systémů). V jakém se služby spouštějí pořadí, to je podle mne důsledek nedokonalosti init+rc - já nechci mít žádné pořadí spouštění služeb, já chci, aby se závislé služby spustily až po té, co mají splněné podmínky pro spuštění.
To, že někdo zná nějaké nástroje, neznamená, že jsou to nástroje vhodné na všechno. Je na to známý bonmot - pokud mát v ruce kladivo, všechno vám připadá jako hřebík. Za jeden z nejsnazších způsobů, jak něco s velkou námahou nevyřešit, považuju situaci, když člověk přestane řešit problém, a místo toho začne řešit, jak by mohl použít nástroje, které zrovna má.
Proč SystemD má speciální nástroj na logování? Protože logování je se správou služeb úzce provázané - SystemD není jediný doplněk/náhrada initu, který řeší i logování. Opět, někde se ještě dnes řeší logrotate, někde rotování logů snad vyžaduje restart příslušné služby - to mohlo být dobré v době svého vzniku, ale snad se shodneme alespoň na tom, že restartovat službu kvůli rotování logů je hloupost. Také u logování se to řešilo postupným vylepšováním - a SystemD se logicky snaží ta vylepšení také používat. Logy v nestrukturovaných textových souborech také nejsou žádná výhra. Vždycky mne fascinovalo, že nikomu nevadí, že se logy nezapisují tak, aby byly 100% strojově zpracovatelné. Takže se klidně může bez nějakého uvozování do logu zapsat znak, který je jinak oddělovačem - a ať si to pak někdo skládá jak chce.
Nevím, proč by se mělo projednávat v širokém plénu, zda si já chci nasadit na server SystemD. No a pokud jsou vývojáři se SystemD spokojeni a dokonce na něm udělají svůj projekt závislý, pokud jsou s ním spokojeni správci distribucí, asi to bude pro většinu lidí dobrý projekt. To přece není špatně. No a pokud chce někdo něco mít jinak, než ostatní, asi se o to bude muset postarat sám.
No a že by se ve světě OSS nejdříve psaly nějaké specifikace a standardy - myslím, že na to moc lidí z OSS nevěří. Používá se opačný přístup - nejdříve se napíše kód, ověří se, jak to funguje ve skutečnosti, upraví se to podle potřeb reálných uživatelů, a pak se z toho případně udělá dokumentované a závazné rozhraní. Na začátku taky Linux neměl spoustu souborových systémů, neměl podporu spousty architektur. Začalo se s jedním, a když se to vyzkoušelo, odladilo a osvědčilo, přidaly se další.
Vy nepoužijete nic z nových vlastností SystemD. To ale neznamená, že to nepoužije nikdo.
Příklad s web serverem - když chceš napsat spouštěč pro web server, musíš napsat skript, kterým popíšeš, jak se ten server spouští, jak se restartuje, jak se vypíná. Jeden se spouští přímo, další se odforkuje a někam zapíše PID, jeden se restartuje signálem, druhý speciálním programem...
Pokud se SystemD dostává do tolika distribucí, asi je dobrý a lidé jej chtějí, ne? Proč když je tak špatný a tolik lidí ho nenávidí, proč ty distribuce neforknou? Nemyslím si ani že by to bylo nucené, ani že by to bylo poprvé v historii linuxu, kdy se nová věc prosadí na úkor té staré.

"Ale nedokáže ji průběžně monitorovat, zjistit okamžitě, že skončila."

Tak pro mě za mě si tam dej: služba || echo "skončila jsem s chybou". Místo echo tam může být třeba příkaz na autodestrukci, když chceš.

Jinak bash je turingovsky úplný jazyk, takže v něm lze napsat totéž co v jakémkoliv jiném turingovsky úplném jazyku. Třeba i něco jako systemd. (Ne, že bych to někomu doporučoval, ale znám člověka, co v bashi naprogramoval podvojné účetnictví.)

"nevím, zda reálně nějaké symlinky vytváří, nikdy jsem takhle nepracoval se službami ani u jiných init systémů"

Aha...

Tak mě napadá, že stejně jako mnozí doporučují systemd "vyzkoušej a potom uvidíš" (systemd mám na debianu jessie od chvíle, kdy se debian rozhodl jej nasadit, protože se mu stejně nevyhnu v RHEL7), tak by možná tito lidé mohli vyzkoušet klasické ovládání unixového typu. Možná by byli překvapeni co všechno je možné udělat s minimem nástrojů a s jakou elegancí.

"Je na to známý bonmot - pokud mát v ruce kladivo, všechno vám připadá jako hřebík."

Tohle ale platí mnohem víc na systemd. Systemd musí dělat všechno, od initu, přes logování, po přihlašování uživatelů, nově je tam dokonce i dhcp server (k čemu proboha každý desktop musí obsahovat dhcp server?). SystemD se snaží být kladivo na všechny hřebíky světa.

"ale snad se shodneme alespoň na tom, že restartovat službu kvůli rotování logů je hloupost"

Ano, to je hloupost. Netuším, jak moc je tohle rozšířené, ale afaik by šlo udělat něco jako že logovací soubor je pojmenovaná pipe a na druhé straně by poslouchal nějaký program, který by ten stream logů ukládal a dělil. Čekal bych, že nějak takhle bude implementován journalctl démon.

"Vždycky mne fascinovalo, že nikomu nevadí, že se logy nezapisují tak, aby byly 100% strojově zpracovatelné."

Proč tě to fascinovalo a proč by logy měly být 100% strojově čitelné? Drtivá většina logů se nikdy nečte, prostě se po určité době smažou. Možná je to dokonce tak, že většina logů se ani nikdy nezapíše (různé embeded systémy s readonly flashkou a logování do ramdisku). Proč za tohoto stavu klást ještě další nároky na logovací systém?

Mě v poslední době přijde čím dál větší tlak na logování a uchovávání všeho co jde. Samozřejmně, různé komerční firmy na tom můžou dobře vydělat, je to oblast "big data" apod. Ale soudný admin (podle mého názoru) by měl těmto tlakům čelit. Nevidím důvod, proč bych měl uchovávat xTB logů. Pro provoz systému je nepotřebuju, tak do /dev/null s nima.

"Pokud se SystemD dostává do tolika distribucí, asi je dobrý a lidé jej chtějí, ne?"

Aneb miliony lidí se nemou mýlit co? Argument počtem bych tu fakt nečekal.

To je fakt marný. Ano, v Bashi jde napsat cokoli. Kdyby měl SystemD stejné vlastnosti jako dnes, ale byl napsaný v Bashi, bylo by to v pořádku, byl bys s ním spokojen? Vůbec nejde o to, v čem je to napsané, ale jaké služby to poskytuje. Kdybych chtěl mít ty služby SystemD, musel bych je dobastlit do každého z těch startovacích skriptů. Není jednodušší, když se to udělá jednou a dá se to k dispozici ostatním?
Nevím, proč bych měl služby vypisovat ls, a které běží zjišťovat nejspíš nějakým šíleným ps a grep em, když můžu napsat rc-status a vidím seznam služeb v jednotlivých runlevelech včetně aktuálního stavu. Nemyslím si, že "klasické ovládání unixového typu" znamená "použít co nejvíc GNU utilit najednou".
Od kdy přítomnost DHCP serveru v projektu SystemD znamená, že DHCP server musí mít každý desktop? Copak to je povinná funkce, která nejde vypnout? To už těžko můžu chápat jako nedorozumění, to je prostě FUD.
Logy by měly být strojově čitelné proto, aby bylo možné je dál zpracovat - vytvořit z nich statistiku, něco v nich vyhledat... Ono nemusí jít jen o strojové zpracování, i člověka může špatné zalomení řádku zmást. To, že má být z logu jasné, co je jaký údaj, mi připadá jako samozřejmost, ne jako "další nárok". A třeba přidat přes pár znaků zpětné lomítko mi nepřipadá jako tak složitý úkol.
Miliony lidí se mohou mýlit. Ale pokud si miliony lidí myslí, že je pro ně něco dobré, nevím, proč ti tak záleží na tom přesvědčit je, že to pro ně dobré není. A když už je o tom chceš přesvědčovat, budou potřeba pádnější argumenty, než "já tohle nepotřebuju".

Takto dlouhé diskuzní vlánko o dvou lidech, to už musí být nějaká duševní porucha, ne?

No, kdybychom si to posílali na soukromé emaily, tak by z toho okolí nic nemělo. V diskusi padly z obou stran zajímavé argumenty, které mohou být pro někoho přínosem. Pokud to někoho nezajímá, tak ať to ignoruje.

Ale možná, že dneska je diskuse dvou lidí duševní porucha, těžko říct. :-D

Doporučil bych panu Jirsákovi i panu Crhonkovi nainstalování následujícího doplňku: https://addons.mozilla.org/cs/firefox/addon/commentblocker/

A zbytek léta pak strávit čtením: https://twitter.com/AvoidComments

"To je fakt marný."

Je

"nějakým šíleným ps a grep em"

Jestli je ps a grep šílený, tak je to fakt marný. Na druhou stranu se tím vysvětluje spousta tvých komentářů v této diskusi. To myslím bez jakýchkoliv postraních úmyslů. Dodnes by mě nenapadalo, že nějaký správce linuxových systémů může považovat výpis procesů a filtr za šílený.

"Copak to je povinná funkce, která nejde vypnout? To už těžko můžu chápat jako nedorozumění, to je prostě FUD."

Zatím se systemd instaluje jako celek. Nelze nainstaloval systemd bez journalctl. Nebo jen journalctl samotný bez zbytku. Tedy v aktuální verzi systemd má dotyčný admin i dhcp server. Není to FUD, je to fakt. Ten dhcp server naštěstí není default zapnutý, ale (v takovém případě) proč tam vůbec je? Je zvykem instalovat pouze to, co je potřeba. Což platí o to víc pro systémové služby.

Jinak logy tady nejsou od toho, aby se z nich dělala statistika. Bohužel jsou někdy ke statistice zneužívány, bohužel jsou zneužívány i k jiným činnostem.

Šíleným ps a grep em jsem nemyslel samotné ty dva programy, ale jejich poskládání tak, abych se dozvěděl, které služby právě běží.
SystemD nelze zkompilovat bez podpory DHCP serveru?
Mimochodem, když se vše tak snadno zařídí pomocí krátký skriptů v shellu, jak se tedy zařídí třeba klasický start webového serveru v nějakém skriptovacím jazyce, třeba Pythonu? Server běží normálně na popředí, informace vypisuje na standardní výstup a chyby na chybový výstup, má běžet pod uživatele a skupinou web:web, naslouchat má na portu 80. To že by měl nastartovat až po spuštění sítě, měl by být zařazený v nějaké cgroup a měl by být kontrolovaný rodičovským procesem, to zatím ponecháme stranou, to není nutnost.

"měl by být zařazený v nějaké cgroup"

Proč?

Na zbytek úmyslně nereaguji.

Aby bylo možné řídit limity té skupiny - třeba si takhle nastartuju pár web serverů, pro každý virtualhost jeden, a chci jim nastavit limit RAM nebo diskové IO.

Nejlépe tak, že každý bude naslouchat na jiné IP adrese.

Tak to neřešte pro tento pro vás supersložitý případ, a řešte to pro případ jednoho serveru.
Jinak je pozoruhodné, že tady někdo řeší SystemD jako zbytečně složitou věc, a vy tady pro obyčejný multihosting vyžadujete virtualizaci.

Nepouští proč? Protože je to moc složité? Nebo protože jiné řešení je lepší? Mně tedy varianta, že každý server běží pod svým uživatelem a se svými limity připadá logická, naopak varianta „nacpeme všechny uživatele do jednoho serverového procesu“ mi připadá jako hack. Virtualizace je zase v mnoha případech kanón na vrabce.

Jak tedy to řešení s Apache a subprocesy zařídí, aby nic z web serveru neběželo pod rootem, a zároveň aby jednotlivé weby byly z hlediska práv oddělené na úrovni operačního systému, tj. aby každý web (IP adresa nebo virtualhost) běžel pod samostatným uživatelem?
Jinak to, že nějak funguje Apache, neznamená, že je to nejlepší řešení.

Aha, takže ono je to se SysVInit všechno jednoduché, ale když má někdo předvést jednoduchý příklad, najednou je to problém.

To záleží na tom, jakou používáte distribuci. Pokud vám distribuce vnutí SystemD s DHCP serverem, je to problém té distribuce, nikoli SystemD. Úplně stejné by to bylo, pokud by v té distribuci bylo SystemD závislé na DHCPD.

A když dříve fungovaly samostatně, fungovaly tak dobře, jako fungují se Systemd?
S tou výhodou zavedení kódu ale zároveň přijdete o všechny ty výhody hlídání, že služba běží, závislostí na službách atd. Není lepší ty krajní situace řešit jinde, než v konfiguraci služeb?

Já jsem ale opravdu nikde nenapsal ani nenaznačil, že by snad kontrola běžícího procesu řešila všechny problémy. Celou dobu píšu jenom o tom, že pokud správce služeb dostane pokyn "zajisti běh serveru", má prostě zařídit, aby ten proces běžel - a když se z jakéhokoli důvodu ukončí, pustit jej znova. Mimochodem, "kontrola běžícího procesu" jste napsal správně - ono nejde jen o to zařídit, aby ten proces běžel, ale opravdu nad ním mít plnou kontrolu. Ono se pak i mnoho věcí dělá mnohem snáz - třeba jen taková prkotina jako restart té služby (na pokyn administrátora). Když má správce služeb ten proces pod kontrolou, zjistí, kdy se proces ukončil a je možné jej nastartovat znova.
Problém se závislostmi není hypotetický - třeba síťový server nemá smysl startovat dřív, než je nakonfigurovaná síť. Často je nejjednodušší nastartovat webový server až po té, co je možné se připojit k databázovému serveru.

"Celou dobu píšu jenom o tom, že pokud správce služeb dostane pokyn "zajisti běh serveru", má prostě zařídit, aby ten proces běžel - a když se z jakéhokoli důvodu ukončí, pustit jej znova. "

Co je tohle s prominutím za kravinu? Tím, že se ten proces bude donekonečna restartovat se jeho běh _nezajistí_. To, že neběží má nějakou příčinu (kdyby tam příčina nebyla, tak by ten proces nespadl), tu je nutné odstranit a potom je možné ten proces znovu spustit. Ten proces poběží mnohem spolehlivěji, když mu admin zařídí správné podmínky pro běh.

Ten proces se nerestartuje donekonečna. Příčina, která způsobila pád procesu, vůbec nemusí znamenat, že ten proces nepůjde nastartovat a nebude spokojeně běžet dalších několik let. Příkladů, kdy něco takového může nastat, už tady bylo napsáno dost. Správné podmínky pro běh admin zpravidla zajistí před prvním spuštěním toho procesu. Vzhledem k tomu, že ne úplně špatně napsaný program si ty podmínky při startu ověří, je navíc jisté, že restartem toho procesu se nic nepokazí. Mimochodem, ani sebelíp nastavené podmínky nezajistí, že ten proces nehavaruje.

Já bych řekl, že to máš jako se starým a novým autem. Takové staré auto bylo v podstatě relativně jednoduchá věc, mohl jsi mu dokonale rozumět a spoustu věcí sis mohl sám opravit. V těch nových je to často samý "black box", kde bez servisu a bez propojení s jejich diagnostickým softwarem s tím často nehneš. No a teď co je lepší? Někdo chce holt jednoduché věci, kterým má šanci plně rozumět a které se snáze opravují, někdo zase chce ty pěkné a komplexní vlastnosti.

Já bych to viděl na přirovnání mezi fyzikou a chemií.

Chemie je zvyklá na to, že má 118 prvků, každá skupina prvků má jiné uspořádání elektronů v poslední vrstvě, různé typy vazeb mezi prvky a celkový počet kombinací je astronomický (afaik dodnes nejsme schopni modelovat molekuly o více než několik málo desítek atomů, za což ostatně byla udělena nobelova cena).

Fyzika je naopak posedlá hledáním jedné, pokud možno krátké, rovnice, kterou by se vyřešelo všechno. Částicová fyzika aktuálně pracuje s relativně malým počet částic (tři generace leptonů, tři generace kvarků, intermediální bosony, higsův boson -- resp. příslušná pole), které maji vlastnosti typu +1 a -1. Některým se i tohle zdá přiliš složité, a přicházejí s jedním základním stavebním kamenem, který má několik málo diskrétních vlastností (superstruny).

Stejně jako IT. Pomocí 0 a 1 uděláte cokoliv. Každý logický obvod postavíte pomocí jednoho typu hradla (NAND). Stačí vám 3 prvky: dvě úrovně signálu a jedna "součástka" a uděláte cokoliv.

Stejně tak unixový přístup. Minimalizace počtu komponent (dokonalé není to, kam nelze nic přidat, ale to, odkud nelze nic odebrat), ze kterých postavíte cokoliv.

Mě osobně je bližší klasický unixový přístup a asi nepřekvapí, že moje formální akademické vzdělání je právě z oblasti fyziky.

Tohle může řešit socket activation, protože i když ta databáze zatím pouze startuje, už je schopna přijmout požadavky (jen si klient bude muset chvíli počkat).

Jiným řešením je, že ten daemon/program přechází na pozadí až poté, co je plně spuštěn. Systemd považuje službu typu forking za spuštěnou až ve chvíli, kdy daemon přejde na pozadí.

Další možností je, že služna je typu notify a sama systemd upozorní, až bude schopna plnit požadavky.

V případě socket activation klient vytimeoutovat může, rovnou se zhroutit však může jen těžko, protože k tomu nevá důvod (spojení bylo navázáno, žádná chyba se skrz něj nevrátila). Pokud služba může startovat i desítky minut, pak je asi fajn použít to notify.

Pokud ve stanoveném timeoutu nepříjde READY, pak se to považuje za selhání a služba je ukončena.

U té poslední otázky si nejsem jistý, jak ji mám chápat. Na svém stroji, který používám pro vývoj, mám mysql nastavenu na socket activation. Když aplikační server potřebuje mysql, tak se prostě spojí s daným socketem a systemd spustí mysql. Aplikační server tedy mysql jako závislost přímo nemá.

Pokud bych chtěl, aby se aplikační server spouštěl až po spuštění mysql, tak bych to udělal prostě úpravou závislostí.

Jinak já se nezabývám správou serverů a nebudu tu správcům říkat, jak je mají spravovat. Pouze zde reaguji na některé nepřesnosti.

Ukončena?! Nebude se ani pokoušet tu závislou službu restartovat?
Pokud je tak nastaven, tak se ji pokusí restartovat.

Mimochodem pro každý server bývá vyhrazený samostatný stroj.
Ono to snad ale v reálu nechodí tak, že by stroj s aplikačním serverem posílal požadavek na jiný stroj, ať spustí databázi, ne?

Njn, to bude asi ten problém.
Ne, to problém nebude. Protože já tu správcům neříkám, jak mají své systémy spravovat.

A jak se to vlastně v běžném serverovém nasazení řeší nyní?

Tisíc? Co je tohle za FUD? Nic ti nebrání to stejně jednoduše udělat i v případě systemd. Vlastně to možná půjde i snadněji, a to včetně automatického spuštění na tom druhém stroji.

Nejsem administrátor, ale tohle bych řešil asi takto: Udělám service typu oneshot. Do ExecStart dám příkaz mysql, který bude mít za úkol spojit se se vzdálenou databází. Přidám tam RequiredBy na aplikační server, takže aplikační server bude záviset na vzdálené databázi, aniž bych musel upravovat service file aplikačního serveru. Jo a ještě do té service přidám, že před spuštěním musí být už ten lokální stroj online. Tolik k těm tvým tisícům řádků kódu.

Což například v systemd řeší sd_notify (viz http://www.freedesktop.org/software/systemd/man/sd_notify.html).

> Neberte to jen jako agitku pro OpenRC,

Jste bohužel jen jeden z mála konstruktivních v této diskuzi... :). Díky za to.

> spíš jsem chtěl ukázat, že se to dá řešit i jinak a že init skripty v Bashi nemusí být jen kupa boilerplate.

To každopádně - nicméně tam bohužel pořád chybí ta supervize (zvlášť u toho php5:). Osobně by se mi líbilo, kdyby non-Linux Debian platformy přešly ze sysvrc shell skriptů na OpenRC, ale tak nějak se mi zdá, že se do toho opět nikdo nehrne... A samo se to bohužel neudělá.

Supervize procesů na popředí v OpenRC by každopádně byla dobrá věc (bez ohledu na systemd).

Myslím, že tím posledním odstavcem jste pěkně popsal situaci, která tady je. Každý řeší jen to, co ho doopravdy pálí :).

Trochu off-topic: Jako praktické cvičení by mě docela zajímalo, jestli by se postfixový a cyrus-imapový supervizor nedal nahradit obecným systémovým supervizorem se socket-activation :).