Vlákno názorů k článku Nebojte se systemd: další komponenty od jaromrax - Zdravim, jasne, je hezke, ze se nekdo ujima uvodu...

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.