Názory k článku Nebojte se systemd: další komponenty

Radsi mi reknete, cim ten journald muzu nahradit.

Jakoukoli implementací Journal API.

Takze systrmd nahradim jinym systemd. To je presne reseni, jake jsem hledal.....

Možná by bylo bývalo lepší nejdřív si zjistit význam zkratky „API“. Možná byste pak nebyl za hlupáka.

To si budou muset zjistit hlavne programatori aplikaci, az budou muset ucit ty jejich pouzivat jine API a maintaineri dister bez systemd, az si budou lamat hlavu, jak prelozit jedno API na druhe, kvuli aplikacim, ktere umi uz jen Poettering API.

Pokud je pro někoho problém použít Journal API, ať to přenechá někomu jinému. Navíc journald hezky funguje i s programy, které logují na standardní výstup – takže vývojář se nemusí učit používat dokonce ani Syslog API a prostě jenom zapisuje na standardní výstup. Což se naučí už s aplikací „Hello World“.

Správci distribucí i vývojáři musí nepřítomnost nějakého API řešit neustále. Když nemáte v systému implementaci Syslog API, budete mít problém pro změnu s aplikacemi, které ho vyžadují. Když v systému nemáte podporu cgroups (třeba protože to není Linux), budete mít problém s aplikacemi, které ho vyžadují.

Ale fakt by mne zajímalo, jaký je podle vás ten klíčový rozdíl mezi Syslog API a Journal API, který způsobuje, že na Syslog API může aplikace bez problémů záviset, ale závislost na Journal API je zlo největší.

Ale fakt by mne zajímalo, jaký je podle vás ten klíčový rozdíl mezi Syslog API a Journal API, který způsobuje, že na Syslog API může aplikace bez problémů záviset, ale závislost na Journal API je zlo největší.

Ano, zavislost na Journal API je zlo nejvetsi, protoze kvuli Poetterigovi nekdo bude muset preorat vsechny existujici aplikace.

Ale my nechceme posílat "simple, plain text log entries", my to chceme dělat moderně, ne tak zastarale jak to dělá dávno syslog (kupodivu syslog implementací je hafo a nikdy nebylo třeba kvůli tomu používat jinou funkci, teď přijde journald a najednou je třeba to posílat přes jinou fuknci, k čemu to?).
A když použiju syslog(...) bude to fungovat pravděpodobně na většině *nix OS, když použiju sd_journal_prin­t(...), bude to fungovat jen pokud mám Linux a jen pokud mi v něm poběží syslog s journald, to je fakt killer vylepšení, bez kterého se nemůže nikdo obejít :-D

1. Apache i NGINX umějí logovat do Syslogu

2. Těžké migrovat není, ale nějak nevím proč bych to měl dělat? Protože se autor systemd rozhodl, že všem bude přidělávat práci? Doteď jsem si myslel, že si komunitně práce ubíráme a přizpůsobujeme se zavedeným věcem a najednou přijde Poettering a najednou, aby se přizpůsobovali jemu a nechali si od něj přidávat práce, zajímavé...

že si komunitně práce ubíráme a přizpůsobujeme se zavedeným věcem a najednou přijde Poettering a najednou, aby se přizpůsobovali jemu....

Jo, ti neprizpusobivi obcane...

Nějak mi není jasné co bych měl jiného logovat než textové zprávy a nějak mi pořád není jasné, co mi journald přináší tak skvělého, že bych do něho měl začít posílat logy a proč je teda v systému nutný další logovací daemon, se kterým jsou často potíže a který nebyl potřeba do příchodu systemd.

To se se systemd stat nemuze. Tam to bude rozesete v binarnim blobu, ktery nejde precist, protoze je patologicky poskozeny.

Když chcete logovat jenom textové zprávy, posílejte je prostě na standardní výstup. Je to ještě jednodušší než Syslog. Mimochodem, tohle je jedna z výhod systemd+journald, na které jste se ptal – v tradičních SysVinit skriptech totiž většinou zprávy posílané na standardní výstup končí v /dev/null.

Da se nejak spustit program, aby logoval na STOUT a zaroven to chytal journald? Napadlo mne pouzit tee - echo TEST | tee | systemd-cat - ale to nefunguje. Jde mi o situaci, kdy je potreba treba neco debugovat a zaroven posilat nekam dal, k dalsimu zpracovani.

Když nevíte, proč byste to měl dělat, tak to nedělejte. Já to třeba vím, protože na svém serveru neprovozuju ani USENET, ani UUCP, ani FTP, zato tam mám databázový a webový server. S čímž Syslog jaksi nepočítá.

Aha, tak uz je to jasne. Oni napsali systemd kvuli Jirsakovi!

Prinasi ti to tu vymozenost, ze se logy zcela pravidelne podelaji, takze zadny logy nemas. To ti usetri namahu s resenim problemu, a zjednodusi to administraci - muzes to cely preinstalovat a vyreseno, ne? PRESNE stejne jako ve widlich.

No to já vím, že se to má schopnost hezky rozbíjet, ale čekal jsem, jestli na to dojdou i ti co to tak děsně obhajují.

Pouzivam rsyslog, trochu mi trvalo,nez jsem to vychytal - proc se tu mluvi o migraci? Rsyslog nebude fungovat nebo co?

Rsyslog bude fungovat. O migraci se tu mluví proto, že někteří lidé prostě nemají rádi systemd, a když proti němu nemají žádný argument, tak si něco jednoduše vymyslí…

K tomu snad lze jen dodat, že revoluce ráda požírá své děti.

Tak s dostatecnou porci horcice, cesneku a pepre by sel sezrat i Poettering.

Nikoli, moje informace je správná, to váš je blud. Rsyslog funguje sám o sobě, a bude tak fungovat dál, journald k sobě vůbec nepotřebuje.

Takze to je tak, ze rsyslog je napojen az za journald? Takze si nesmim zmenit logovani v journald na "none", jinak by mi byl rsyslog k prdu?

Hmmm. Ale z toho mi plyne, ze kdyz si pred rsyslog stoupne dalsi program, tak nekdo udelal znova to, co uz fungovalo (u me teda dobry) a logicka ambice je nahradit to. To jsem zvedav...

- Koukam, ze slovo migrace jsem tu pouzil jenom ja :)

Ne, Rsyslog není napojen za journald. Aplikace, které logují přes Syslog API, tak mohou logovat pořád dál a budou logovat přímo do Rsyslogu. Jenom aplikace, které umí logovat jenom přes Journal API, budou logovat do journald a to bude zprávy přeposílat přes Syslog API do Rsyslogu. A nebo samozřejmě někdo může napsat jenom malou knihovnu, která bude volání Journal API rovnou překládat na Syslog API.

To, co spustí systemd a loguje na standardní výstup, může logovat třeba přes multilog (logovací nástroj, který je součástí správce služeb daemontools od DJB). Použití journald není povinné, jenom je to celé pro journald předkonfigurované, takže vám to bude fungovat rovnou – zatímco pro využití jiného řešení si budete muset něco nakonfigurovat sám. Ale pořád je to opensource, takže pokud bude hodně lidí chtít logovat nějakým jiným způsobem, vzniknou pro to návody a podpora v distribucích, a vy si jen při instalaci vyberete, zda chcete logovat přes journald nebo třeba přes metalog.

Takže musím přepsat unity tak, aby se vše volalo přes multilog a stejně to půjde do journald, který stále musí běžet?
Ano, musel byste v unitách přesměrovat standardní výstup do multilogu. Do journald by pak z té aplikace nešlo nic, ale předpokládám, že journald by stejně musel běžet, protože by do něj aspoň systemd logoval přes Journal API.

Nemůžu říct systemd tady máš komponentu co implementuje tvoje logovací api (předpokládám, že by se musela napsat) a posílej to do ní a nespouštěj journald?
Teoreticky by to jít mělo, Journal API je veřejné a jasně definované. Ale nevím, jak moc je do systemd zadrátované, že používá zrovna jednu konkrétní implementaci. Předpokládám, že je to jenom na úrovni sestavení kódu - a že současná implementace Journal API je součástí libsystemd, kde jsou i jiné funkce, a že by tedy stačilo implementaci Journal API vytrhnout z této knihovny a umístit do samostatné knihovny tak, aby bylo možné používat dál libsystemd, ale vedle toho použít jinou implementaci Journal API. Ale je to jenom můj dohad, nedíval jsem se, jaké knihovny přesně s jakým obsahem se sestavují. Na druhou stranu předpokládám, že se tohle bude zlepšovat s tím, jak budou skutečné alternativní implementace vznikat - dnes by to oddělení do samostatné knihovny bylo zbytečné.

Kvuli tomu, aby jounald prestal vytvaret /dev/log a mohl ho napr. spravovat rsyslog, tak kvuli tomu musim patchovat, kompilovat atd. systemd-journald? Omg, na to, ktere sockety chci otevrit, ma mit journald konfiguracni volbu.

A to je ten problem lidi kolem systemd, kdyz to nedava smysl jim, tak to nemuze davat smysl ostatnim. Presne nevim, kdo/co vytvarelo socket /dev/log pred systemd, zda rsyslog apod., udev ci neco dalsiho, ale pokud budu predpokladat, ze to dela rsyslog (napr. RHEL 6.x/CentOS 6.x), tak rsyslog je velice modularni a jednotlive moduly si mohu vypnout ci zapnout. A prave ta nemodularnost systemd v nekterych situacich a nemoznost vypnuti nekterych vlastnosti je trnem oku spouste lidi - napr. integrace udev, stejne jako pouzivani pro spoustu neprogramatoru/ad­minu nepruhledneho dbusu (tedy aspon pro mne).

Priklad - nechci resit jak funguje journald, umim lepe rsyslog, chci mit jako primarniho logovaciho demona rsyslog (protoze filtry, rulesety atd.) a journald jen pro ty "moderni" aplikace, ktere pouzivaji jeho API.

Osobne systemd a jeho dalsi komponenty/nastroje povazuji za zajimavy a potrebny posun nekam, ale nemusel(y) by tolik slapat na moje prsty.

Priklad - nechci resit jak funguje journald, umim lepe rsyslog, chci mit jako primarniho logovaciho demona rsyslog (protoze filtry, rulesety atd.) a journald jen pro ty "moderni" aplikace, ktere pouzivaji jeho API.
Nastavíte v journald.conf ForwardToSyslog=y­es. Co je na tom složitého, nemodulárního, co na tom nemůžete vypnout?

uz ses naucil exportovat obrazek?

Coze, logy systemd se ted exportuji jako obrazek?

Nic sloziteho na tom neni, ale odporuje to pozadavku "chci mit jako primarniho logovaciho demona rsyslog ".

Tak slozite to neni. A systemd s binarnimi logy, ktere lze vyexportovat do obrazku, ma tu vyhodu, ze kdyz to clovek potrebuje parsovat, tak staci prohnat to skrz OCR.

Pod požadavkem "primární logovací démon rsyslog" si představuju, že aplikace, které logují přes Syslog API, logují přímo do rsyslogu. Tento požadavek splněn je. Pokud jste tím požadavkem myslel i to, že aplikace logující přes Journal API logují přímo do rsyslogu, pak nechápu ten další požadavek, že do journald mají logovat pouze aplikace používající Journal API.

Abychom se konečně dohodli, já jsem váš požadavek pochopil takhle:

app1 ------------------------\
                              \
app2 -------------------------+------> rsyslog
                             /
systemd ---> journald ------/

Nebo jste to myslel jinak?

Díky. Ta možnost s Rsyslog vypadá zajímavě.
Chápu to správně, že tímto způsobem by se vše co jde přes systemd nebo používá journald API logovalo pomocí rsyslog i s možností strukturovaných logů a journald by vůbec nemusel běžet?
Snad reaguji na správné vlákno. Můžete mít logování nakonfigurované tak, že aplikace používající Syslog API budou logovat přímo do syslogu. Aplikace používající Journal API budou logovat do journald, který strukturované zprávy převede na text a ten zaloguje do rsyslogu. Journald tedy musí běžet (zajišťuje logování pro Journal API), ale nemusí nic ukládat do svého logu, zprávy bude pouze transformovat a předávat dál do Syslogu. Aplikace používající Syslog API logují přímo, těch se journald nijak netýká.

Bylo by možné napsat i přímo rozhraní z Journal API do syslogu (tj. neřešit to v aplikaci journald, ale v knihovní funkci), ale pokud vím, zatím, taková implementace neexistuje.

Pane Jirsak, to ze lide systemd nemaji radi je vas takovy jakoby soukromy myslenkovy konstrukt.
No, zrovna nedávno byl v jednom dotazu tady v poradně systemd usvědčen, odsouzen, zlynčován a popraven, načež někdo vznesl takovou trapnou připomínku, že systemd v daném systému vůbec není. Na soukromý myšlenkový konstrukt mi to připadá docela živé.

Jinak já jsem nikdy netvrdil, že mi systemd nadmíru vyhovuje, a také jsme nikdy netvrdil, že musí vyhovovat všem. Právě naopak, vadí mi, když někdo tvrdí, že systemd nevyhovuje jemu, a tím pádem je špatné a nemůže vyhovovat nikomu. A ještě víc mi vadí, když někdo prostě jenom nemá rád systemd, argumenty proti němu nemá žádné, tak si je prostě vymýšlí. Přeborníkem v tomto oboru se stal Jarda_P, který už argumentuje jenom tím, co systemd nedělá, ale dělat by mohlo.

A jestli jste si všiml, já nejsem Jarda_P a stejně tak se mnou jednáte.
Osobně jsem nikoho a nic nepopravoval :D

A jestli jste si všiml, já nejsem Jarda_P a stejně tak se mnou jednáte.

Kdybys kvotoval, emusel bys zamenou tolik trpet. Ta diskuse je tu udelana tak uzasne, ze od urcite urovne se v tom ani prase nevyzna. Hlavne, ze ted vsichni maji tyhlety sirokouhle monitory a Root ma responzivni layout.

A já netrpím, spíš si díky tomu dělám názor na ty, co se tak chovají.

Jj diskuze tady smolík, ve chvíli, kdy se začne reagovat, tak se to totálně znepřehlední a je problém, kdyby to aspoň nějak signalizovalo na koho se odpovídalo...

ad "No, zrovna nedávno byl v jednom dotazu tady v poradně systemd usvědčen, odsouzen, zlynčován a popraven, načež někdo vznesl takovou trapnou připomínku, že systemd v daném systému vůbec není."
Tak to prostě je. Když vám nepřizpůsobivý soused bude krást slepice a vy ho u toho nachytáte, logicky z každé další chybějící slepice obviníte jeho. A většinou i správně. Ale může se stát chyba a může v tom být nevinně, ale v takovém případě člověk podvědomě používá presumpci viny. Systémd je prostě (zatím) zmetek a s tím vaše agitace nic nenadělá. Kecy o přeposílání logů si nechte, když se rozsype ten binární pseudolog, sesype se ten bazmek komplet i s přeposíláním a nemáte nic. A to, že se to sesype, to je téměř jistota. Argumenty netřeba vymýšlet, argumentů je spousta a vaše agitace je na to krátká. Jediné co dokážete je tvrdit, že to systémd dělá správně a kompatibilitu likviduje jen proto, že to předtím bylo špatně. Ale to je ve většině případů jenom váš názor a dovolím si tvrdit, že je to špatnej názor. Systémd možná něco málo opravuje, ale za cenu rozbíjení celé koncepce.

Tady je to ovšem trošku jiný případ. Někdo napíše do diskuse nějaký blud o chování systemd, který je následně vyvrácen. Další napíše, že by se systemd nějak mohlo chovat, i když se tak zatím nechová. To se několikrát zopakuje. No a pak ti, které nezajímají fakta, klidně něco hodí na systemd, přestože nikdy nikdo nezaznamenal, že by systemd něco takového dělalo, a přestože systemd v daném počítači vůbec není. Vždyť už toho přece o systemd četli tolik špatného.

když se rozsype ten binární pseudolog, sesype se ten bazmek komplet i s přeposíláním a nemáte nic
Máte pro tohle své tvrzení nějaký důkaz? Nemáte, že. Ale proč si na systemd neplivnout tvrzením "nechová se tak, ale mohlo by". Těm, které nezajímají fakta, jste přispěl do sbírky dalším komentářem o tom, jak je systemd špatný - přestože jste si to vymyslel.

Argumenty netřeba vymýšlet, argumentů je spousta
Proč tedy nějaký nepoužijete? Proč si místo toho vymýšlíte?

Smutné je, že rozsypaný log už jsem se systemd zažil několikrát a fungovalo to přesně tak, jak jsem napsal. A stačí si do googlu zadat "systemd corrupted journal" a ejhle.... 27000 výsledků... a všichni si vymýšlí, nikomu se to nestalo a vy máte pravdu. Já jsem nikdy nenapsal, že se nějak může chovat a proto je to zmetek. Já tvrdím, že mám OSOBNÍ ZKUŠENOSTI s tím, co všechno dokáže doku*vit a proto je to podle mě zmetek. A ne, nezajímá mě, že 30+ let starý systém logování má svoje mouchy a proto jej někdo předělává k obrazu svému. Ať si předělává, ať to udělá líp, já budu rád, pokud to bude další možnost, která pro mě může mít v některých případech řadu výhod. Ahle hlavně mě zajímá to, že když se něco stane, chci mít log. U starého jsem si možná zanadával, ale bylo to stokrát lepší, než mít nečitelnou poškozenou binární sra*ku a k tomu prázdný remote log.

Zajímalo by mne, jestli trollíte, nebo jestli ty bludy opravdu nevidíte. Napíšete, že journald dělá chyby při zápisu do svého logu a že také journald dělá chyby při předávání do syslogu. Já se zeptám, zda máte nějaký důkaz pro ty chyby při posílání do syslogu, na což vy odpovíte, že máte osobní zkušenost s chybami při zápisu do logu journald. Tedy odpovíte přesně na tu druhou polovinu, než na kterou jsem se ptal. Nebo-li tvrdíte, že platí A a B, já se zeptám, jaké máte důkazy pro B, načež vy začnete sáhodlouze dokazovat A. Vidíte ten rozdíl? Chápete, že když vedle se be uvedete dvě tvrzení, důkazem jednoho tvrzení jste neřekl vůbec nic o tom druhém tvrzení? Chápete, že chyba při přeposílání do syslogu se neprojeví tak, že bude „corrupted journal“?

To vaše neustálé dehonestování zdejších lidí, co se mnohokrát setkali s problémy, které vznikají nasazením systemd či jeho nějakých nových částí je dost odporné.

Tuxík vám jasně napsal, že má špatné zkušenosti s rozbíjením logů, které způsobuje integrální součást systemd a sice journald. A že to nezachránilo ani přeposílání do syslogu. Vy jeho slova překroutíte k obrazu svému a tvrdíte, že řekl (napsal) něco co neřekl (nenapsal) a stavíte na tom své závěry. To není diskuze, to je lynč. Běžte s takových chováním někam!

A že to nezachránilo ani přeposílání do syslogu.
To právě nikdy nikde nenapsal. Psal o rozbitém zápisu do journal logu, uváděl odkaz na Google na rozbitý zápis do logu, a k tomu přilepil, že vlastně nefunguje ani to přeposílání – bez jediného argumentu.

To právě nikdy nikde nenapsal.

To je divné, že já to z toho co napsal pochopil, že?

A víte, že mně zrovna na tomhle vůbec nic divného nepřipadá?

Předkládám osobní zkušenost s tím, co se mi stalo. Asi 3x. Bohužel, logy jsem si neschoval, protože se nezapsaly. Příště si to vyfotím, abych měl nějakou potravu pro trolla. Chyba přeposílání do syslogu se neprojevila tím, že by byl corrupted journal, ale kvůli corrupted journal se sesypal celý journald a to včetně přeposílání. Výsledkem je ŽÁDNÝ LOG!, což je úžasné, protože vlastně nemusím nic řešit. Bohužel, i přes všechny trolloviny se momentálně journald NEDÁ vypnout bez zásadního vlivu na systém, jedinou možností jsou volby Storage=none a ForwardToSyslog=yes a to se vyplatí - další do sbírky nesmyslů k nekonečnému zvedaní padajících služeb - už jen za tuto funkcionalitu bych STŘÍLEL, nemá na serveru co dělat.

kvůli corrupted journal se sesypal celý journald a to včetně přeposílání
To, že je poškozený log journald, a to, že poškozený log journald způsobí, že se zprávy nepředávají ani do syslogu, jsou dvě naprosto odlišné chyby. Tu druhou jste popsal poprvé právě teď.

Pokud si necháváte logy přeposílat do syslogu, připadá mi Storage=none jako jasná volba, a moc nechápu, proč by to někdo chtěl mít jinak.

Ne. Jasná volba by byla v tomto případě celý journald vyhodit, protože je to pouze nesmyslný zabugovaný bazmek v cestě, něco jako retardér uprostřed dálnice. Ale to bohužel nejde. Jinak je zcela běžné třeba přes rsyslog zapisovat log lokálně i vzdáleně a klidně hádej proč. Což pořád můžu, ale stále budu mít v cestě ten retardér, kterýmu - pozor! - ZCELA SUBJEKTIVNĚ A TENTOKRÁT BEZ KONKRÉTNÍHO DŮVODU - prostě nevěřím, protože už mi v minulosti způsobil jiné problémy a nevidím žádný objektivní důvod, proč bych mu měl svěřit zbytečnou funkci papouškování zpráv od aplikace k logovacímu daemonu, který se tím na něm stává závislý a bez něj nebude fungovat (kecám, fungovat bude, protože to není systemd, ale nebude mít vstupní data).

No me by se zas libilo, kdyby autori aplikaci zacali pouzivat CEE-enhanced syslog messages - cee.mitre.org a rsyslog.com - a v zakladu implementovali logovani na STOUT, do souboru a pres syslog, aby si uzivatel/admin mohl vybrat, kam to chce poslat. Pak by stacilo rozsirit logovaci knihovnu o meta-informace, ktere ma journal a journal by treba nebyl potreba.

Třeba Journal API? To API na ničem dalším nezávisí, můžete ho použít klidně i ve Windows.

Nezávisí? Jen na journald, který ve Windows není, že? :D

Koukni na to API, to vazne k implementaci SystemD nepotrebuje. Z vetsi casti je to cviceni pro druhaky.

Jaká jiná aplikace umí přijímat má data přes to API v *nix like systémech? (Windows mě nezajímají, já s nimi nezačal)

Aplikace? Mohli by všichni odpůrci systemd diskutující v tomto vlákně hned teď odejít dostudovat si význam zkratky API a teprve po té se vrátit a pokračovat v diskusi, pokud to ještě bude účelné?

Tak můžete prosím vysvětlit, když pošlu přes Journal API data, co je teda přijme, když to nebude aplikace?

Dotaz byl, jaké použít API. Vy se teď ptáte na to, jakou použít implementaci logovacího démona, který podporuje Journal API. No já bych doporučil journald, je to v současnosti jediná implementace, o které vím. A myslím, že by neměl být problém portovat ji na jiné POSIX platformy, protože si nemyslím, že by měla nějaké komplikované závislosti.

To, co vy nazýváte „API journald“, systemd nazývá „Journal API“, což tomu rozlišení od journald může trochu pomoci.

Vysvětlovat to mi (programátorovi), je zbytečná práce. Já tyhle věci vím. Akorát mi pořád není jasné, jak to použiju jinde, jak tady někteří tvrdí, že to jde, protože podle mě, když je implementace Journal API jediná a sice pouze v systemd, který je pouze pod Linuxem, tak to prostě jinde (jiné *nix like OS, Windows ap.) nefunguje. Bohužel jsou tu jedinci, kteří tvrdí, že to používat jde, ale odpovědi jak se to udělá, když to jinde neexistuje jsme se stále nedobrali.

Ano přesně tady jsem vás chtěl dostat, děkuji, že jste se nakonec odhalil.

Abych tedy shrnul vaši radu: Abych mohl naprogramovat aplikaci, ve které chci "moderně" logovat, musím si k tomu napsat i pro každý systém mimo Linuxu i logovacího démona, který bude implementovat Poetteringovo API. :-D

Přiznejte se, že jste byl toto léto moc dlouho na sluníčku.

PS: A když je to tak mega super cool věc, jak to že ještě nejsou hromady implementací toho API na všech možných i nemožných OS, aby se s tím každý programátor nemusel mrcasit sám?

Jj jasně, tonoucí se stébla chytá. Na některých OS bude stačit knihovna na jiném bude nutný i daemon. Slovíčkaříte a uchází vám podstatná pointa. Takhle to mají puberťáci, že bazírují na kravinách a podstata jim uniká.

PS: A k čemu bych posílal strukturovaná logovací data přes nějakou zvláštní novou knihovnu do syslogu, který strukturu nemá místo toho, abych to posílal syslogu přímo na všech *nix like platformách, to už mi asi taky nevysvětlíte, ale hlavně že je nutné dělat vlastní implementaci API, které na dané platformě neexistuje. :D

Tak se podívejte pořádně. Já žádné strukturované logování nechtěl, mě bylo nuceno a když jsem se zeptal, proč je to tak super skvělé, tak jsem se dověděl, že proto, že si musím na všech ostatních platformách kromě Linuxu se systemd naimplementovat vlastní a když to udělám, tak na hromadě platforem to stejně jen převedu ze struktury do textu. Rada jak noha :D

Tak si to sám vyzkoušejte. Napište si jednoduchou Hello World aplikaci a přidejte si do ní logování přes Journal API. Přidáte #include <systemd/sd-journal.h>, zavoláte sd_journal_print. Aplikaci přeložíte.

Co jste právě udělal? Naprogramoval jste aplikaci, která loguje přes Journal API. Musel jste naprogramovat logovacího démona pro každý systém mimo Linux? Nemusel. Takže buď umíte zázraky, nebo jste právě předvedl protipříklad ke svému tvrzení.

A praktický důvod, proč bych tu aplikaci o to logování do Journal API přidával, když chci multiplaformní a nikde jinde než v systemd to nejde se prostě nedozvím a nedozvím. Ale spoustu keců, jak jsem blbej, že si mám naimplementovat API na plaformách kde není to jo. :D

Normálně uvažující lidi mají nejprve nějaký problém (např. potřebuji logovat strukturované zprávy) a k němu hledají řešení (použiju Journal API). Vy jste se nejprve rozhodl, že použijete Journal API, a teď zoufale hledáte nějaký důvod, proč jste se tomu vlastně rozhodl.

Mám pro vás takový radikální návrh. Když nevíte, proč byste něco používal, tak to nepoužívejte.

Co mi to vkládáte do úst? Já vůbec Journal API nechtěl používat. Já naopak na začátku říkal, že journald a jeho API je vlastně k ničemu. Ale byl jsem přesvědčován, jak je to super věc a když jsem se zeptal proč, tak jsem se dověděl, že proto, že si ho můžu všude možně na různých platformách naimplementovat :D

Pokud ho nechcete, nemusíte ho používat. Pokud Vám stačí řádkové logy, tak si dál logujte přes syslog nebo na standardní výstup jak jste zvyklý a na Journal API zapomeňte.

Me by zajimalo, jak dlouho to jeste bude mozne a kdy aplikace prestanou rozumet Syslog API a bez systemd nebudou umet logovat.

Aha, takže do vlákna o použití Journal API jste přišel jenom trollovat. Aspoň že to přiznáte.

To nebyla neochota něco pochopit, ale uvědomění si, že s tím bude kdekoli jinde potíž a proč to tedy vůbec používat. Doteď nemám kloudnou odpověď a pochybuju, že kromě té "naimplementovat si to sám", že ji vůbec dostanu.

PS: A když je to tak mega super cool věc, jak to že ještě nejsou hromady implementací toho API na všech možných i nemožných OS, aby se s tím každý programátor nemusel mrcasit sám?

Za tim stoji zpatecnictvi a zavist lidi, kteri nedokazi ocenit neci genialitu.

Nic proti, ale po tom co jsi tady napsal je potřeba úspěšně pochybovat o tom, že jsi programátor. Každy slušný projekt přesahující jakousi minimální hranici (definujme ji například cca 1000+ SLOC) loguje buď na standardní výstup/error výstup pokud nemá extra potřeby (třeba i kvůli Dockeru) nebo používá nějakou slušnou logovací multiplatformní knihovnu (pro každý jazyk jich bývá přehršel). A v těchto knihovnách si jednoduše nakonfigurujete, kam všude to má jít. Není jen standardní výstup/soubor/sys­log/rsyslog, loguje se do logstashe/gra­ylogu/fluentd, existují mraky cloudových logovacích služeb (ani nebudu vyjmenovávat). Takža kam se loguje je otázka změny konfigurace. Normální programátor neřeší API logovacích knihoven.

Na mne tyhle diskuse dělají dojem, že si tady honí trika správci ojedinělých serverů, občas o sobě prohlašující, že jsou programátoři. Opravdový programátor nebo správce opravdu rozlehlé sítě by nikdy něco takovéhohle nemohl napsat.

Proc bych mel v aplikaci resit jestli to pujde do logstashe atd. kdyz to muzu lokalne poslat do syslogu a z nej pak dal? Jde mi o to neresit zmeny (treba IP/DNS logovaciho serveru) na X ruznych mistech, ale pouze na jednom - v konfiguraci syslogu.

Ano to je taky přesně ta věc, co mi vadí. Proč bych měl měnit hromady aplikací, když taková věc má být konfigurací té komponenty, která ji má v systému na starost (v *nix like systémech syslog)? Poettering vyrobí novou (nespolehlivou) službu a nutí takhle ostatní, aby ji používali a to tímhle způsobem. Takhle se to podle mě nedělá.

Příklad nucení ostatních do změn je v poslední době v rozbití funkčnosti screen, tmux ap. a pak vysvětlování jeho nohsledů v diskuzi tuším právě u tmuxu, že to mají opravit oni. Mám obavu, že tohle není poslední věc, kterou budou autoři systemd tímto způsobem tlačit a problémy ohledně nové logovací služby to podle mě dokazují.

Normální programátor neřeší API logovacích knihoven.

Ano a to je v podstatě ten problém, na který jsem upozorňoval. Běžný (osobně se mi vaše dělení na normální a nenormální nezdá) programátor to nemá co řešit. A proto se mi to nabízené řešení v podobě toho, že si to má sám naimplementovat nelíbí.

PS: Vaše pochyby směrem ke mě rozebírat nebudu.

Řešení, že si to máte sám implementovat, je váš vlastní nápad, který tu pořád prosazujete. Všichni ostatní vám radí, ať použijete nějakou univerzální knihovnu pro logování a nesnažíte se řešit detaily, kterým nerozumíte.

API je definováno mezi logující aplikací a libsystemd (je to Journal API), nikoli mezi libsystemd a journald (tam je to implementační záležitost). Když chcete nahradit journald, napíšete vlastní implementaci Journal API, a aplikace nepoběží s implementací Journal API z libsystemd ale s implementací z vaší knihovny. A ta vaše knihovna třeba vůbec nemusí komunikovat s dalším běžící procesem, ale může rovnou zapisovat na disk.

Jak jste přišel na to, že Journal API závisí na journald? Viděl jste to API vůbec?

Tak to API na journald zavisi tim, ze je to jeho jedina implementace. A vzhledem k tomu, ze Poetterig to API jeste treba 20x zmeni, tak se do alternativni implementace asi nikdo nepozene.

Tak to API na journald zavisi tim, ze je to jeho jedina implementace.
To ovšem nechápete význam zkratky API. To, kolik je implementací, není věcí autorů API.

A vzhledem k tomu, ze Poetterig to API jeste treba 20x zmeni, tak se do alternativni implementace asi nikdo nepozene.
To jsou akorát vaše ničím nepodložené kecy.

LOL!

Otázka: Jak použiju Journal API jinde než v Linuxu a systemdd?

Odpověď Jirsáka: Úplně normálně, API je API a můžete to použít třeba i na WIndows

Otázka: Ale když to jinde než v Linuxu a SystemD neexistuje, jak to teda použiju?

Odpověď Jirsáka: To ovšem nechápete význam zkratky API. To, kolik je implementací, není věcí autorů API.

To už je na Chocholouška toto :D. A prej neexistující problém jak je výše psáno. Jasně, hned jdu do Windows programovat pomocí Journal API, které Windows nepodporují :D :D :D

Já do toho Windows tahat nezačal, já ne. To si vyřiďte s těmi, co tím začali argumentovat, tak mě zajímalo, jakže se to teda dělá. Takže to na mě neházejte. Já mluvil o *nix like OS a argumentátoři začali s Windows. Zajímavé, že jim neřeknete, že se chytali stébla.

To, že nechápete pojem API, není zas taková tragédie, rozhodně to není na Chocholouška. Na Chocholouška je to, že místo abyste si to zjistil, píšete pořád různé nesmysly založené na nesmyslných představách o tom, co je API.

Zkusím to ještě jednou. API je rozhraní mezi dvěma softwarovými komponentami. Použití API znamená, že dokážete zavolat funkce poskytované tím API. API může mít nějaké podmínky použití a závislosti – např. pokud bude funkce vyvolána zasláním zprávy dbus, je takové API závislé na dbus. Pokud se funkce vyvolává zasláním zprávy vytvořené přes funkci CreateEvent Win32 API, bude to API závislé na Win32 API. Journal API je tvořené pouze voláním C funkcí, takže nemá žádné závislosti a je multiplatformní.

Jako programátor Journal API použijete tak, že do svého zdrojáku includujete příslušný hlavičkový soubor a zavoláte funkce v něm deklarované. V závislostech své aplikace pak uvedete, že k běhu potřebuje (volitelně nebo povinně, záleží jak jste to implementoval) implementaci Journal API. Tím to pro vás končí, neřešíte, kde je jaká implementace, stejně jako neřešíte, kde vaše aplikace sebere implementaci funkce fopen nebo SSL_accept.

Když pak někdo chce vaši aplikaci použít, musí nejprve splnit všechny její závislosti. Když bude potřebovat implementaci SSL_accept, použije třeba LibreSSL – a to přesto, že v době, kdy jste psal ten program, LibreSSL ještě vůbec nemusela existovat a jediná implementace SSL_accept byla v OpenSSL. Úplně stejně je to s Journal API. Vy dneska napíšete aplikaci používající Journal API, a vůbec vás při programování nemusí zajímat, jaké existují implementace. Ten váš program může zítra někdo vzít a spustit s implementací, o které jste ani nevěděl. Dokonce ten program můžete napsat i tehdy, když neexistuje vůbec žádná implementace toho API. A v tom je právě celá výhoda API a jeho smysl – vy jako programátor se nestaráte o konkrétní implementace, je vám jedno, jestli není žádná, je jedna nebo jich je padesát, je vám jedno jestli zítra přibyde dalších dvacet implementací, protože pro vás se tím nic nemění, vy píšete pořád proti tomu jednomu API.

Z toho je mimo jiné patrné, že vaše věta „Windows nepodporují Journal API“ je nesmyslná. Žádná podpora Windows není potřeba. Když někdo napíše implementaci Journal API pro Windows, můžete pod Windows Journal API klidně používat – na Windows samotných se přitom nic nezmění, v Redmondu nebudou muset hnout ani prstem, aby Windows nějak začaly podporovat Journal API. To, zda můžete nějaké API v daný okamžik někde použít, je totiž závislé pouze na jeho závislostech a na dostupných implementacích. Pro použití API nepotřebujete žádnou podporu operačního systému.

Tolik k původní otázce autora programu, jaké multiplatformní API může použít. Vedle ní je také možné položit otázku uživatele: mám aplikaci vyžadující implementaci Journal API. Jakou implementaci Journal API mám použít? Což je ovšem jiná otázka, než ta, která byla na začátku tohohle vlákna.

Cituji

--- cut ---
- Žádná podpora Windows není potřeba

- Když někdo napíše implementaci Journal API pro Windows, můžete pod Windows Journal API klidně používat
--- cut ---

Já se bavím o tom co je ne o tom, co by kdyby.

Koukám, že Lael má mohutnou konkurenci. Zbytek vašeho příspěvku je OT vata.

odpůrce strany → ohledně odpůrců strany...

Tak jak si přejete, abych vás nazýval? Společným znakem všech vašich komentářů je, že se snažíte dát všemožně najevo, že nemáte rád systemd – i za cenu, že ze sebe uděláte úplného hlupáka. Pokud jediným projevem někoho je, že nemá rád systemd, jak jinak ho nazývat, než odpůrce systemd? Já vím, že systemd-hater je výstižnější a ironicky to odkazuje na způsob pojmenování binárek v systemd, ale já anglicismy nemám rád, takže to moc nepoužívám.

Kdybyste kritizoval systemd, psal byste věcné komentáře, argumentoval byste něčím, u čeho by se dalo věřit aspoň tomu, že si myslíte, že je to pravda, nenazýval bych vás odpůrcem systemd. Všimněte si, že takový komentář napsal na konci diskuse například Heron, a odpůrcem systemd jsem ho nenazval. Dokud v tom tématu reagoval věcně NULL, ani jeho jsem tak nenazýval. Ale když nekritizujete, jenom prezentujete svůj odpor, proč bych vás měl nazývat jinak?

Jj jak před '89... Kdo nesouhlasil, byl hned nepřítel lidu :D.

Vzhledem k tomu, že systemd nejen používám, ale řeším hromadu problémů, reportuji chyby, analyzuji kde chyba vzniká, zkouším najít opravy a taky je často nacházím si nemyslím, že jsem odpůrce nebo hater systemd, ale jak říkám, neznamená, že si z toho kusu softu budu dělat modlu, obzvlášť, když hromadu věcí dle mého názoru (na který mám po '89 nárok) dělá špatně.

Ještě jednou a naposledy, třeba to pochopíte: za odpůrce systemd neoznačuju ty, kteří nesouhlasí, ale ty, kteří neváhají psát nesmysly a vymýšlet si, jenom aby předvedli, že systemd nemají rádi.

Pokud to ani tentokrát nepochopíte, omlouvám se vám za označení „odpůrce systemd“ – v takovém případě to neděláte schválně, ale prostě jenom nechápete význam textu.

A nebo vy nechápete význam psaného textu a to, že když se s daným problémem nesetkáte vy, že neexistuje.

Tak si pojďme některé ty problémy rozebrat. Problém č. 1 - bez systemd nejde spustit linux (obecně). S tímto problémem jsem se nesetkal, ale myslím, že snadno prokážu, že neexistuje - mám totiž zařízení bez systemd, na kterém linux jde normálně spustit. Problém č. 2 - v budoucnosti nebude možné logovat jinak, než přes systemd. V současné době ten problém neexistuje (což lze opět snadno prokázat systémem, kde se loguje a není tam ani systemd ani journald). Teď je přítomnost, ne budoucnost, takže teď ten problém neexistuje. Problém č. 3 - uživatel Libcha chce ve své vlastní aplikaci logovat stejně, jako na daném systému loguje systemd. Uživatel ByCzech má problém s tím, že takové logování není multiplatformní a že vlastně vůbec neví, proč by měl logovat přes Journal API. Uživatel Libcha je někdo jiný, než uživatel ByCzech, takže uživatel ByCzech se laskavě přestane cpát do toho, co Libcha chce nebo nechce. Problém vyřešen.

Pokračovat můžete vy, protože byste mohl tvrdit, že schválně vybírám ty případy, kdy to dotyčným jenom ujelo a neexistující problém vytvořili omylem. Tam sem s nějakým reálným problémem, který já jsem označil za neexistující.

Aha, diskuze je fakt nepřehledná, pak se neví kdo na koho reaguje...

Aha, diskuze je fakt nepřehledná, pak se neví kdo na koho reaguje...

Jo, ale na to tu lidi upozornujou tepre asi jen pul roku. Nemuzes chtit, aby kazda chyba byla vyresena do druheho dne. Nejdriv se to musi responzivne promyslet.

Já už na to neupozorňuju, je to zbytečné. Vzhledem k těm chybám co tu jsou a nikdo s tím nejen nic nedělá, ale ani to nikoho nezajímá.

Každopádně jedna věc je nepřehlednost a druhá chování Jirsáka, který často místo věcné diskuze očerňuje nebo se staví do role samozvaného správce téhle diskuze, který má problém s chápáním toho co mu ostatní chtějí sdělovat. Slovíčkaří a trvá na svém chápání toho co kdo napíše, ačkoli se mu to snaží diskutující vysvětlit, že jim jde o něco jiného a uniká mu podstata příspěvku ap.

Ještě jste zapomněl na ty, kteří nechtějí implementovat API do všech svých aplikací
Nezapomněl. K tomu, aby aplikace mohla běhat v systému, který používá systemd, nemusí autor té aplikace implementovat žádné API, nemusí napsat ani čárku. Pokud někdo tvrdí opak, spadá do kategorie těch, kteří si prostě jen vymýšlí. Nikoho jsem neoznačil za odpůrce systemd proto, že by nevěděl, co je API.

Vite, ta "špinavá práce" nemusí být až tak špinavá.
Když se probíráte špínou, což je současný stav SysVinit+skripty, není to čistá práce.

Ta vaše metafora s mostem vůbec nesedí. My dneska nemáme několik starších mostů, které nevyhovují. My dneska máme děravou loď, holinky, bidlo, děravý záchranný kruh a spoustu leukoplasti, vytipované místo v řece, kde je mělčina a dá se tam postavit, když se člověk topí, a k tomu do detailu vypracovaný postup, jak se s pomocí těchhle propriet dostat na druhý břeh. A když někdo namítne, že děravá loď není úplně ideální dopravní prostředek, hned přijde někdo s tím, že proto je tam přece ten záchranný kruh a každý ví, kde má z loďky vyskočit a kde je ta mělčina, na které si může odpočinout – a nějaké novoty jako neděravou loď nikdo nepotřebuje.

V takové situaci neseženete prostředky na postavení drahého dálničního mostu někde vysoko nad údolím, lidé si takový most ani nebudou umět představit, a ani nebudete vědět, jak na to. Takže nejprve musíte postavit dřevěnou lávku nízko nad vodou, budou z ní schody k té mělčině, kde odpočívají topící se, bude u něj molo pro připoutání té děravé loďky, budou na něm zásobárny leukoplasti na ten záchranný kruh atd. A teprve až si lidé zvyknout, že nemusí jet děravou loďkou, topit se a teprve pak vylézat na most, ale že mohou přes most přejít z jednoho břehu na druhý, teprve pak jim můžete navrhnout pořádný most, který nebude omezený tím, že u něj musí být molo pro zakotvení děravé loďky a nemusí z něj vést schody do odpočívárny pro topící se.

Těch náhrad SysVinitu, které se snažily řešit jen malou část a postupně, bylo docela dost – a systemd vzniklo jenom proto, že žádná z nich neuspěla.

Protože odporoval, nařkl jste ho že neví co je API.
Ne. Nařkl jsem ho, že neví, co je API, protože v komentářích předváděl, že neví, co je API – například tvrdil, že API závisí na implementaci, nebo že aplikace využívající API musí vědět o tom, jaké všechny implementace API existují.

Dneska ohledně procesů si lidi dokážou představit co je potřeba. Jinak by to asi ani P-Team nemohl dělat, kdyby nevěděli co je vůbec potřeba.
Někteří lidé si to představit dokážou a jiní ne.

kdo che chodit po té vratké lávce, tak už nesmí měnit za loďku, případně mu stavitelé mostu zruší některé ty mělčiny nebo kotviště
Tak to ale není. Kdo se rozhodne používat most, klidně se zase může vrátit k loďce. Mělčiny nebo kotviště mu nikdo neruší. Ale je pravda, že když se někdo rozhodne, že tu loďku pro jistotu potáhne po mostě za sebou, že to nebude komfortní a bude to dokonce namáhavější, než s ní jet po vodě (než se potopí). Ale tahat za sebou loďku po mostě nebyl nápad tvůrců mostu.

Vratká lávka, po které přejde 99 suchou nohou a jeden se namočí (navíc vlastní nepozorností) mi připadá jako výrazný pokrok oproti stavu, kdy se jich namočí sto a je to vnímáno jako normální součást překonání řeky.

Já k té myšlence a snaze P-Teamu nic nemám, ale zdá se mi že to přehánějí a tak trošku prasí okolo. Bohužel . . .
Já vás chápu, přemýšlel jsem o tom několikrát, jestli to nepřehánějí. Ale vždy jsem dospěl k tomu, že se mi nechce riskovat, že by systemd byl další neúspěšný pokus, a za 3 roky se bude řešit to samé, jenom v ještě horší situaci a bude potřeba být ještě drsnější. Ty méně drsné metody už se zkoušely a neuspěly.

například tvrdil, že API závisí na implementaci, nebo že aplikace využívající API musí vědět o tom, jaké všechny implementace API existují.

Myslím, že by jste to měl dokázat nebo se omluvit.

Protoze vsichni vime, ze centos 7 == linux.

Konfiguracny subor /etc/grub2.cfg, riadky zacinajuce na linux, dopisat na koniec riadku init=/bin/bash. Prajem Vam vela zdaru a pevnych nervov pri praci s takto spustenym systemom.

Před lety, na centos 5, to vůbec nebylo složité. Mount disků, ip a / ip r nastavení sítě. service sshd start. Zbytek po síti.

Já jsem ale nikde nepsal, že rozběháte CentOS 7 bez systemd. Já jsem pouze vyvracel vaši lež, že bez systemd nespustíte linux. To, že CentOS 7 je linux na věci nic nemění, protože vy jste tvdil, že bez systemd nespustíte (žádný) linux, což rozhodně nelze dokázat jediným příkladem (ale jediným příkladem to lze vyvrátit).

A to je problém... Někomu systemd přidělá spoustu starostí a problémů a hned je to odpůrce!

Kde je fix laudon ta pověstná svobodná možnost volby, kterou jsem si na Linuxu tak oblíbil?

Že to nepomůže v jednom případě neznamená, že to nepomůže nikdy.

Ano, takže místo toho aby se psali programy správně a testovali se (Její pojetí asynchronního softwaru, plánování priorit, důkladného testování a ošetřování chyb způsobených chybným zadáním), tak se to bude zbůhdarma restartovat a třeba se to zrovna povede, pokud jsou hvězdy nakloněny. Ostatně, kdyby tam byl systemd, tak po restartu naběhnou všechny services jako před tím (protože konfigurace je přece jen jedna a je nesmysl to dělit na boot a aktuální, že).

Navíc zrovna v případě Mars Climate Orbiter to byl ten samý problém

To nebyla chyba vstupu, to byl vadný program. Nepředpokládám, že by tam někde byla tabulka fyzikálních konstant, kterou stačilo jen na dálku přeflashnout, tohle všechno bylo jistě zadrátováno do programu. Ostatně, kdyby tam byla, tak by si toho asi i někdo všiml.

PS: Jinak po včerejším kompletním výpadku DC Master Internet Praha nemám chuť dál flamovat. Mimochodem, půl dne nejelo ani Internet Info a nikde ani čárka. Počkáme do zítřka ;-). Každopádně toto ukazuje, s čím se musejí sysadmini potýkat. Vůbec to není problém padajících services. Za posledních několik let jsou to hlavně krajně nespolehliví dodavatelé, kteří LŽOU. Včera se provalila LEŽ o tom, že Master má zálohované redundantní napájení.

Ano, takže místo toho aby se psali programy správně a testovali se (Její pojetí asynchronního softwaru, plánování priorit, důkladného testování a ošetřování chyb způsobených chybným zadáním)
Ne místo. Správně napsaný a otestovaný program je takový, který se v neočekávané situaci přepne do bezpečného režimu, ve kterém nepáchá žádné škody a pomáhá při diagnostice problému.

zbůhdarma restartovat
To je vaše konstrukce.

To nebyla chyba vstupu, to byl vadný program.
Byla to chyba na vstupu. Nejdřív dostali od sondy údaje o aktuální rychlosti, které byly mimo očekávané hodnoty, sonda pak naopak dostala příkaz k manévru mimo očekávané hodnoty.

protože konfigurace je přece jen jedna a je nesmysl to dělit na boot a aktuální, že
po včerejším kompletním výpadku DC Master Internet Praha
Ano, je to nesmysl, protože jak ukazuje mimo jiné ten včerejší výpadek, můžete si klidně myslet, že máte zálohované redundantní napájení, ale stejně je potřeba počítat s tím, že server bude najednou z ničeho nic bootovat (protože to zálohované redundantní napájení už zase běží) a vy k němu navíc nemáte přístup (protože port na switchi není po tom neplánovaném výpadku tak zcela v kondici). Nebo-li pokud najednou z ničeho nic bootuje server, nebo najednou z ničeho nic startuje služba, měly by vždy skončit v nějakém bezpečném stavu. Pokud tedy administrátor pracuje způsobem "teď mám systém v jiném stavu, než do kterého by se dostal po bootu, ale správce služeb mi do toho hrabat nebude a dá-li Bůh, k restartu nedojde", docela hazarduje.

Někdo zkrátka počítá s tím, že správně napsaný program se nikdy neočekávaně neukončí, běží na serveru, který se nikdy neočekávaně nerestartuje, a je umístěn v datacentru, kde nikdy nedojde k výpadku napájení. A pak jsou lidé, kteří na tohle nespoléhají, a řeší, aby i v případě toho neočekávaného výpadku systém skončil v bezpečném stavu. Takže třeba aplikace, která se spouští v okamžiku, kdy nebyla řádně ukončena, naběhne v režimu pouze pro čtení, aby bylo možné zkontrolovat, že nedošlo k nějakému skrytému poškození dat. A nebo ještě lépe, aplikace v takovém okamžiku naběhne v režimu jen pro čtení a sama spustí diagnostiku. Takže až se k ní správce přes ten nefunkční switch probojuje, budou už na něj čekat výsledky, že je vše v pořádku a jestli je možné se přepnout do plného provozu.

stejně je potřeba počítat s tím, že server bude najednou z ničeho nic bootovat

S tím se kupodivu počítat dá a vždy se s tím počítalo i v minulosti s oddělenou konfigurací pro boot. Mimochodem, tohle tady (se slovníkem sobě vlastním) komentovat j. A velmi trefně.

To se stalo zrovna našemu ex-konkurentovi (nebo jak to nazvat) minulý týden, který si k nám do racku dal svůj hw. Po prvotním nastavení na místě si to chtěl donastavit z kanclu a ejhle, co čert nechtěl (nebo možná chtěl), uklepl se v iptables pravidlu a odřízl si síť kompletně.

Stačilo přes monitorovací rozhraní poslat impuls reboot, počkat až to najede, a bylo to OK (načetla se původní konfigurace). Kdyby to nastavoval přes hypotetický sd-firewalld stylem "je jen jedna konfigurace", tak aby ani reboot nepomohl, protože po bootu by se mu tam opět načetlo to špatné pravidlo (a ne každý HW má na mgmt grafickou konzoli, takže by tam musel někdo dokráčet).

Pokud tedy administrátor pracuje způsobem "teď mám systém v jiném stavu, než do kterého by se dostal po bootu, ale správce služeb mi do toho hrabat nebude a dá-li Bůh, k restartu nedojde", docela hazarduje.

Viz. Výše. Nikdo nepsal o tom, že k výpadku nikdy nedojde. Jen jsem psal o tom, že se těžko jedná s dodavateli, kteří lžou. Ten včerejšek byl jen vhodným příkladem takových lhářů.

S tím se kupodivu počítat dá a vždy se s tím počítalo i v minulosti s oddělenou konfigurací pro boot.
V tom případě nechápu ty nářky na to, že systemd připojil souborový systém nebo spustil službu - protože přesně to by se stalo po bootu.

Stačilo přes monitorovací rozhraní poslat impuls reboot, počkat až to najede, a bylo to OK (načetla se původní konfigurace).
To musí být děsně prima. Upravím konfiguraci firewallu, za několik týdnů někdo jiný aktualizuje jádro, musí provést restart serveru, a načte se mu jiná konfigurace firewallu. A ještě lepší to bude v případě výpadku napájení - server naběhne, něco v síťování nebude fungovat (kvůli chybně nastavenému firewallu), všichni budou řešit, co se tím výpadkem napájení pokazilo, a ona je to akorát chybná nikdy nepoužitá konfigurace firewallu.

Řešit chybnou konfiguraci služby restartem celého systému je oblíbený způsob ve Windows. V unixovém světě se to řeší tak, že se připraví nová konfigurace, ta se aplikuje dočasně, a pokud hrozí, že by si mohl správce odříznout přístup, nastaví si časový limit, po kterém se vrátí předchozí konfigurace automaticky.

Mimochodem, tohle tady (se slovníkem sobě vlastním) komentovat j. A velmi trefně.
Pokud se mi někdy přihodí, že souhlasím s tím, co napsal j, zamyslím se nad tím ještě jednou a hledám, kde je v mých úvahách chyba.

V tom případě nechápu ty nářky na to, že systemd připojil souborový systém nebo spustil službu - protože přesně to by se stalo po bootu.

To už jsme probrali. Může na ten server spadnout meteorit. Ano, může. Příčetný admin si nebude rebootovat stroj, u kterého vyměňuje disk. Elektřina zpravidla nevypadává (pokud omylem nemáte server v DC Master Praha). Pokud by vypadla, tak by to příčetný admin nechal najet do nějakého rescue režimu. Nebo by se zařídil jinak. Fakt nevím, co je to za argument: stejně by se to stalo po bootu.

To musí být děsně prima. Upravím konfiguraci firewallu, za několik týdnů někdo jiný aktualizuje jádro, musí provést restart serveru, a načte se mu jiná konfigurace firewallu.

Velmi se omlouvám, že jsem to pro vás nenapsal jasně, pohybuji se mezi adminy, takže jsem předpokládal (moje chyba), že všichni vědí, že se ta konfigurace při bootu dá změnit. Takže: ve chvíli, kdy si dotyčný nastaví ten fw tak, že je s ním spokojen, může toto nastavení uložit i pro příští boot.

Takže s tím, že server bude najednou z ničeho nic bootovat, se samozřejmě počítá, až na výjimky, kdy se s tím nepočítá.

Jistě, dá se tak pracovat, ostatně dělali jsme to tak spoustu let. Akorát v tom nevidím jedinou výhodu, zato tam je dost příležitostí pro chyby. Připadá mi lepší mít jednu nebo více konfigurací (třeba pro běžný běh a záchrannou konfiguraci), mezi kterými se přepíná podle definovaných pravidel nebo na pokyn administrátora, ne rebootem.