Názory k článku Co se systemd… a Linuxem

I systemd má konfiguraci v /etc.

Samotný service file nepovažuji za konfiguraci.

A to je právě to. Proč hledat alternativu k systémům které systemd obsahují? Ano, možná se zdá systemd složitý, ale na rozdíl od jiných svobodných projektů má alespoň dokumentaci a poměrně dobré manuálové stránky, což se například o různých ConsoleKitech, PackageKitech (které se taky pěkně infiltrovali do spousty distribucí) říci nedá.

Moment, to naozaj?

Teda, nie ze by to nedavalo zmysel, ale aj tak, ten ConsoleKit, co rozmlatil 3/4 Archu pred rokom ma na svedomy ten isty magor, co systemd?

Mně připadá, že bez té funkce to není žádný systém, bez toho máte jen sadu nějakých skriptů nebo konfiguračních souborů, které akorát určí, v jakém pořadí se má co nastartovat. Někomu to klidně může stačit. Jenže i ten původní SysVinit má respwan procesů, má runlevels, takže evidentně tam na začátku byla nějaká snaha, aby to fungovalo jako správce služeb. Akorát se od té doby trochu změnila doba a typická služba není terminál naslouchající na sériové lince, ale síťový server, který závisí na spoustě jiných služeb.
Já tedy vnímám systemd jako pokus, jak to, co musí být nad SysVinitem dobastleno pomosí spousty skriptů (a pak to zase neumí využívat ty původní funkce initu jako respwan), udělat jako jednu komponentu odpovídající dnešním požadavkům. Způsob implementace nebo nasazování může být sporný, ale k cíli, který systemd má, můžu říct jenom „no konečně“.

"Nez propadne call na dotycneho technika tak je minimalne pulhodina v haji ne-li, dele protoze clovek na druhe strane indovi nerozumel a vola primo na ops centrum."

Jestli on náhodou není problém někde jinde, než v init systému ;-)

"Nez propadne call na dotycneho technika tak je minimalne pulhodina v haji ne-li, dele protoze clovek na druhe strane indovi nerozumel a vola primo na ops centrum."

"Problém je v tom, že to programátor nenapsal dost robustně."

Ve firmě, kde "call" na technika trvá půl hodiny a kde si jednotliví zaměstnanci vzájemně nerozumí, je také docela dobře možné, že to programátor nenapsal dost robustně, to zcela jistě.

Jak jsem psal, problém je v něčem zcela jiném, než v init systému.

Nemocné služby je přece potřeba opravit, jak tu bylo opakovaně napsáno. Takže je potřeba tu službu opravit, aby nepoškozovala data ale používala žurnál a kontrolní součty.
Ještě vám chybí protipříklad pro službu, která žádná data na disk nezapisuje. Předpokládám tedy, že tušíte, že tvrzení „existuje služba, kterou je nejlepší po pádu hned znova nastartovat“ nelze vyvrátit tvrzením „existuje služba, kterou po pádu nelze hned znova nastartovat“.

"Logování na server v journalctl"

Tak fajn, ještě před několika lety to tam nebylo. Konečně se journalctl blíží klasickým syslogů,

"Logování do paměti jsem ocenil"

Logování do paměti lze snadno rozběhat i se syslogem. Prostě /var/log připojíte na tmpfs či jiný fs v paměti. Všimněte si, jak je toto řešení univerzální, nezávisí na tom, zda tuto funkci poskytuje samotný program a lze jej použít i na jiné věci, než jen logy.

...a kdyz ti na takovemto mountu dojde misto?

...ktery jsem vytvoril prave pouzitim toho "reseni".

typicka situace:

nejaky proces se zblazni a do logu zacne hustit giga nejakych debugovacich hlasek. nebo treba brute force password attack na ssh. nebo logy z netfilteru od podivnych packetech. proste cokoliv co zacne floodovat log. (a ne, vsechno to neuhlidas).

to nasledne vede k tomu, ze v lepsim pripade se logovani zasekne (coz je jeste ok, pokud sluzba jede, ale stejne je neprijemne, ze clovek netusi, co se deje prave TED - ma jen stare logy). v horsim pripade (a to byva castejsi) se kvuli tomu podela kde co (napriklad protoze do /var nejde odkladat data nebo failujici logovani shodi proces, ktery se snazi logovat, coz je nase dulezita sluzba, ktera musi bezet, atd...).

no, anebo nebudeme bastlit vlastni "chytra reseni" a proste pouzijeme logovani do pameti, tak jak je skutecne zamysleno (kruhovy buffer) a mame po problemech.

To nieje typicka situacia, to proste mate sluzbu, ktora je kodena na h...

Miesto vymyslania workaroundov by ste mal riesit sluzbu, ktora Vam zabija logovanie. Alebo nasadte logrotate.

Neviem, mne sa ani ten logrotate v takomto pripade moc nepaci. Pretoze nez taketo riesenie, to uz moze to logovanie rovno vypnut - pokial tam sluzba spamujuca log bezi, stejnak z neho nic rozumne nedostane.

Takze neopravovat logovanie, ktore robi to co ma, opravovat sluzbu.

"nejaky proces se zblazni a do logu zacne hustit giga nejakych debugovacich hlasek"

Už i starý syslogd na tohle pamatoval a opakující se hlášky do logu nezapisuje. Jen jejich počet.

Vy proste robite to, co DenyHost automatizuje, rucne. Jasne, nic proti tomu, aj to je riesenie. Pravdepodobne spolahlivejsie, nez DenyHost pod Archom :(

Len taka drobnost, neuspesne prihlasenia sa pod Archom (a hadam i vsade inde) vzdy logovali do toho isteho suboru - /var/log/auth.log. V tomto journalctl ziadnu vyhodu nepriniesol.

Obávám se, že /etc/default je něco úplně jiného.
Myslím, že celý tenhle problém má prapůvod v odvěkém problému zapracovávání uživatelských změn konfigurace při upgrade. Málo která distribuce má tak propracovaný systém jako třeba dispatch-conf u Gentoo. Většinou se starý konfigurák nechá na místě a nový se pleskne vedle s nějakým .rpmnew a admine, starej se. To zpětně přidělává problém vývojářům, kteří nemají jak vynutit zavedení nových výchozích konfigurací, které třeba opravují známé problémy. Cesta, kterou používá udev a systemd tenhle problém částečně řeší, ale jen částečně.

Naplno se to ukázalo třeba s konceptem nových šílených jmen síťových rozhraní (ano ano, já vím, že je to rozbité, ale u svého systému s jednou síťovou kartou chci mít eth0 a nic jiného). K zablokování stačilo vytvořit prázdný soubor /etc/udev/rules­.d/80-net-name-slot.rules, který překryl upstreamový konfigurák zodpovědný za přejmenování. Jenže pak přišla verze 210 a soubor se v upstreamu přejmenoval na 80-net-setup-link.rules. Připadá mi to jako hra na kočku a myš.

Co zatím funguje, je parametr net.ifnames=0 na příkazovém řádku kernelu. Otázka je, na jak dlouho.

"Konfigurace by ale nemela byt mistem, kde se resi opravy ..."

+1

„Konfigurace by ale nemela byt mistem, kde se resi opravy ...“

Teorie hezká, nicméně výchozí konfigurace je součástí toho, co se dodává uživatelům, objevují se v ní chyby a je často potřeba je opravovat alespoň těm uživatelům systému, kteří si té konfigurace nejsou vůbec vědomi a tedy ji neměnili. Aneb, nic není dokonalé.

Jde o glosu k soucasnemu stavu, doplnenou o relevantni odkazy a takto by se k tomu melo pristupovat.
Jinými slovy, jde o mišmaš dvou velmi různých textů. Asi jako kdybyste spojil kabaret a dokument do jednoho televizního pořadu.
Jak k tomu tedy mám přistupovat? Jako ke glose, kde se od autora nečeká, že by něco analyzoval, a možná trochu přehání? Takže ten seznam odkazů nemám brát zas tak vážně, autor si v něm možná také vymýšlí, o některých programech moc neví, a kritériem výběru byla spíš vtipnost než co jiného? A jak mám chápat poslední odstavec? Je to ironie, není z čeho vybírat a na směřování svobodného software nemáme žádný vliv?
Víte, ono to oddělování a dodržování různých stylů má svůj důvod, čtenář ke každému textu přistupuje jinak. Návod si nebudu číst pro zábavu a glosu zase nebudu brát jako zdroj faktů.

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?