Zdravim,
jasne, je hezke, ze se nekdo ujima uvodu do systemd, to je treba ocenit, ale serial ve me spis vyvolava paniku.
Sluzba systemd-tamedated - divny jmeno, neni to preklep? Takze ntpd, ktery normalne dela svoji praci tak co - skonci? Jeste bych umel pochopit systemctl start ntpd, ale tohle je pro me matouci. Budou tedy bezet dva konkurenti?
A ten journalctl - jaky je vztah a rozdil k/s dmesg napr.? Kolik ma linux logu?
Desi me, ze by to mohlo byt jako na windows, kde pisou, ze cas je synchronizovany a mam 17 sekund posun proti ostatnim a ja nevim, co s tim, rucni klikani neni reseni.
Sluzba systemd-tamedated - divny jmeno, neni to preklep?
Je to překlep, má to být systemd-timedated.
Takze ntpd, ktery normalne dela svoji praci tak co - skonci?
Existovalo n klientů NTP, teď jich existuje n+1. Pro těch n to neznamená nic.
Budou tedy bezet dva konkurenti?
To by zrovna u synchronizace času bylo velmi nevhodné. Prostě si vyberete jednu z n+1 implementací, tu, která vám nejvíc vyhovuje.
Kolik ma linux logu?
Kolik chcete. Nejlepší je, když na jednom systému používáte jeden.
A ten journalctl - jaky je vztah a rozdil k/s dmesg napr.?
journald při startu zkopíruje aktuální výstup dmesg do svého logu a dmesg na sebe přesměruje, takže máte jaderný i aplikační log na jednom místě.
Desi me, ze by to mohlo byt jako na windows, kde pisou, ze cas je synchronizovany a mam 17 sekund posun proti ostatnim a ja nevim, co s tim, rucni klikani neni reseni.
To nezávisí na systemd, ale na konkrétní implementaci NTP klienta, kterou použijete. Přičemž zrovna ntpd (referenční implementace) je podle mne na podobné chování také náchylná. Mně se stalo, že byl čas posunutý o několik měsíců, a ntpd se tvářil, že je všechno v nejlepším pořádku. (Byla to chyba konfigurace – to, že ntpd řeší jen malé odchylky času a na skokové seřízení času při startu systému se má použít třeba ntpdate je dokumentované chování.)
Takze ten timedate nepotrebuju a nebude se mi tam cpat, kdyz uzivam ntpd. Ok.
Journald - tak jestli je to kopie, a logy do /var/log/ mi dal fungujou jako dosud, tak mi snad ani nevadi, dalo by se rict, ze muzu nekam dat to journalovani 'none' a na funkci agronoma to nebude mit vliv...ne?
17sec. - o ntpd uz dlouho vime sve a uz ho umime pouzit. Ted jen najit verzi pro win10.
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_print(...), 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
kupodivu syslog implementací je hafo a nikdy nebylo třeba kvůli tomu používat jinou funkci
A proto Apache a nginx používají syslog a vůbec si neudržují vlastní logy, že?
A když použiju syslog(...) bude to fungovat pravděpodobně na většině *nix OS, když použiju sd_journal_print(...), 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
Psal jsem o tom, jak je „těžké“ migrovat. Případně to jde rovnou udělat tak, že tam dáte #define syslog sd_journal_print. Samozřejmě pokud použijete funkce, které syslog neumí, tak se to pak těžko implementuje syslogem a budete muset napsat něco, co to překlopí.
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é...
Apache i NGINX umějí logovat do Syslogu
Používá to vůbec někdo? Syslog třeba nedokáže rozumně oddělit vhosty či HTTP od HTTPS. Systemd nabízí jednotné řešení i pro strukturované logování, které se dosud řeší tak, že každý démon loguje sám, ve vlastním formátu a s různě dobře fungující správou logů (třeba delaycompress je super workaround nebo real-time centralizace logů se dělá pomocí neustálého pollování souborů).
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?
Někdo tvrdí, že by to bylo nutné? Journald bude i nadále podporovat syslog. Akorát pokud chcete něco víc než jen textové zprávy, tak holt budete muset použít Journal API, a pro ty případy lze začít jednoduše převodem syslog na sd_journal_print a strukturovat jen to, co zrovna potřebujete.
Vždyť je to zmíněno i v tom příspěvku! Apache i nginx už teď strukturují svoje logy tím, že je rozdělují do více souborů. Což je velká sranda, když je potřeba ladit něco, co jde napříč vhosty. Nebo pokud to jde z nginxu do PHP-FPM a MySQL. To se velmi dobře ladí, když je výsledek 500 Internal Server Error a různé části důvodu jsou rozesety po nejméně pěti souborech.
2Sten: Nj, nekdo jako ty nemuze tusit, ze 99,9% linuxovych appek umi logovat do vlastniho !!!! TEXTAKU !!!! a variantne pouziva systemovej log - a Apache to umi taky.
A vis proc se to v pripade Apache moc nepouziva? Protoze sysadmina vazne nezajimaji ty tuny logu ktery generuje. To zajima mozna admina webu, a tan se v nich muze rochnit pekne extra.
2ByCzech: 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.
2Jirsak: Kdybys mel paru o tom, jak systemd nefunguje, tak bys tu nezvanil takovy bludy. Veskery logovani pres ni musi protyct, co neprotece pres, to neexistuje.
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í.
Zase půlka informací. Rsyslog bude fungovat pouze, když bude fungovat journald. Takže v případě problémů, řešíte věc navíc.. Apropó ten argument o nepřenositelnosti vám asi nic neříká, že. Však je to chyba jiných, že nenapsali další implementace, chápu to správně? No jo, je to takové pragmatické. K tomu snad lze jen dodat, že revoluce ráda požírá své děti.
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.
Já si dovedu představit cestu přes dynamický linker, ale je to trošku (dost) hack. Systemd skoro jistě používá libsystemd, která obsahuje implementaci těch funkcí z Journal API. Vhodný LD_PRELOAD by mohl podstrčit vlastní implementaci, která by journald obešla.
Ale jinak se obávám, že autoři systemd nepočítají s tím, že by umožnili vyměnit backend pro samotné systemd.
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é.
Ak nestojite o strukturovane logovanie tak si mozte Vas system nakonfigurovat tak, ze do journalu bude logovat iba samotne systemd. Ako priklad vezmem CentOS 7 (situacia/konfiguracia v inych distrach moze byt mierne ina)
V CentOS 7 vytvara AF_UNIX socket /dev/log systemd. resp. journald ak mu nie je predany pri spusteni od systemd. Aplikacie pouzivajuce POSIXove syslog API sa pripajaju a zapisuju aplikacne logy na tento socket. journald zapisovane data spracovava. Aplikacie logujuce cez nativne Journal API komunikuju so journald cez iny socket. Oba zdroje logov journald uklada do suborov v /run/log/journal (/run je na tmpfs)
Rsyslog bezi vedla journald a pouziva Journal API na citanie logov. Rsyslog dalej logy ziskane zo journalu uklada a spracovava podla svojej konfiguracie, typicky uklada persistentne do /var/log/messages.
Nic z toho co som vyssie popisal nie je vytesane do kamena. Ak by som chcel postavit system ktory pouziva na spracovanie logov z /dev/log/ Rsyslog, tak staci zmenit prislusnu konfiguraciu Rsyslog. Dalej je potreba zabranit journald v praci s /dev/log. Na to staci velmi jednoduchy patch [1]. Dodatocne je potrebne vypnut prislusnu socket jednotku u systemd (systemctl --now disable systemd-journald.socket).
Vacsina spravcov distribucii stoji o strukturovane logovanie a teda je na Vas aby ste "isiel proti prudu" alebo zvolil alternativne distro.
Volba na to nie je pretoze, ona to je primarna funkcia toho daemona a mat na to konfiguracnu volbu nedava zmysel. Konfiguracia, ktoru som popisoval je pre softwarovych fundamentalistov, ktori jednoducho nechcu journald pouzivat za kazdu cenu. Ja som iba chcel demostrovat to, ze je to mozne dosiahnut relativne jednoducho, ale stale to obnasa nejaku pracu. Tu holt musi clovek ktory pouziva distribuciu XY, ale zaroven neveri v zdravy rozum a usudok spracov distribucie vynalozit.
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/adminu 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=yes. Co je na tom složitého, nemodulárního, co na tom nemůžete vypnout?
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. Lide spis nez ze ho nemaji radi ho nepotrebuji, protoze jim castokrat neprinese nic noveho, nicmene znacne zneefektivni praci. Ze vam systemd nadmiru vyhovuje neznamena, ze vyhovuje i jinym. Chapete rozdil, nebo toho nejste schopen a co je dobre pro vas je automaticky dobre pro ostatni?
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.
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!
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.
Pokud nějaký program loguje na standardní výstup, můžete ten výstup přesměrovat do souboru, jako dřív, nebo ho můžete přesměrovat do journald.
Pokud nějaký program loguje přes Syslog API, můžete ho nechat logovat přes libovolnou implementaci Syslogu – přičemž jendou z těch implementací je journald.
Pokud nějaký program loguje přes Journal API, můžete ho nechat logovat přes libovolnou implementaci Journal API (v současné době existuje asi jediná implementace, a tou je journald).
Vše, co je logováno přes journald, můžete nechat zapisovat do nativních souborů journald, nebo to můžete nechat přeposlat přes Syslog API do jiné implementace Syslogu.
Takže pokud jste měl logy ve /var/log, můžete je tam mít i nadále. Jediné, co budete muset vyřešit nově, jsou aplikace, které logují jenom přes Journal API (tedy obvykle součásti projektu systemd). Pokud do /var/log logujete přes Syslog, můžete do něj přesměrovat i journald. Pokud jste do /var/log logoval výhradně přímo z aplikací, asi nezbyde než použít nějaký Syslog, protože journald přímo do textových souborů logovat neumí. Ale takovu variantu nepředpokládám, snad na každém systému běží nějaká implementace Syslog API, i když se třeba nepoužívá pro všechny aplikace.
Pokud nějaký program loguje přes Syslog API, můžete ho nechat logovat přes libovolnou implementaci Syslogu – přičemž jendou z těch implementací je journald.
Pokud nějaký program loguje přes Journal API, můžete ho nechat logovat přes libovolnou implementaci Journal API (v současné době existuje asi jediná implementace, a tou je journald).
Tedy lze ocekavat postupne odemirani Syslog API a prechod na Journal API, az systemd bude zcela a totalne nevybouratelny a distra bez systemd budou muset implementovat mezidaemon, ktery to bude prekladat z jednoho na druhe.
to, že ntpd řeší jen malé odchylky času a na skokové seřízení času při startu systému se má použít třeba ntpdate je dokumentované chování.
Aha, no pokud se stejnou erudicí přistujete i k systemd, tak ten seriál je použitelný jen jako lehký úvod k systemd (takovým dojmem na mne stejně od začátku působil).
Je to děsné kam až ten root.cz klesá.
Nejsem autorem seriálu (autor článku je uveden vždy na začátku článku vpravo nahoře). A také nejsem autorem dokumentace k ntpd:
In case there is no TOY chip or for some reason its time is more than 1000s from the server time, ntpd assumes something must be terribly wrong and the only reliable action is for the operator to intervene and set the clock by hand. This causes ntpd to exit with a panic message to the system log. The -g option overrides this check and the clock will be set to the server time regardless of the chip time. However, and to protect against broken hardware, such as when the CMOS battery fails or the clock counter becomes defective, once the clock has been set, an error greater than 1000s will cause ntpd to exit anyway.
Máte pocit, že mé stručné shrnutí neodpovídá tomu,co je v dokumentaci? Nebo že se ntpd nechová podle té dokumentace? Nebo co přesně se vám nezdá?