Vlákno názorů k článku
Devuan 6.0 Excalibur je postavený na Debianu 13 a nepoužívá systemd od Youda - Ja popravde nechapu to saskovani proti systemd. Systemd velice...

Jestli to nebude spis tvoji lenosti ... pouzivam treba metalog, a co kam se bude logovat si snadno nastavis, pokud to nejak logovat umi a umi se to nejak itentifikovat, tak to muzes libovolne rozdelit. Muzes snadno docilit i toho, ze budes mit jeden log kde bude "vsechno" a zaroven dalsi kde to bude rozdelene, coz se hodi kdyz hledas nejaky casovy souvisloste.

Jup a jsou to textovy soubory na ktery ti vi/cat/... staci.

Pekny, lec ja nyni, ve stoleti ančovičky, vidim vsade prosty journald, coz, pro debug tracing naprosto postacuje a umim si z nej udelat "oddelene logy" prepinacem --unit.

A kde je potreba delat s logama krapet vazneji, cpe se to do vzdaleneho OpenSearch, kde se daj ty data prosivat v ramci cele farmy kooperujicich serveru.

"Pekny, lec ja " ... o logovani nic nevim. To si chtel rict? Logy jsou totiz zajimavy predevsim v situaci, kdy neco crashne, a logovac systemd crashuje jako prvni.

A kupodivu a neprekvapive, kdyz crashne logger, tak se ani do vzdalenyho logovace nic nezapise ... ja vim, divny.

Ju vlastne, ja zapomel, systemd "resi" problemy tak, ze vsechno porad dokola restartuje.

Co je tak těžké pochopit na větě: "Nic méně já jsem nepsal, že systemd je špatný init systém, já jsem psal, že do něj byly naházené věci, co tam prostě nepatří."?

Já jsem nikdy neměl problém se systemd jako init systémem, ale má zůstat init systémem a ne celým userlandem (a to prostě tlačil Poettering). Chápete to, nebo to potřebujete nakreslit?

No vzhledem k tomu, ze jste si vyfabuloval neexistujici komponenty vlastne neni zrejme, co ze povazujete za chybnou soucast. A opet utocite na cloveka, ale ono tady se nebavime o nejake one-man show.

Takže to bude potřeba asi nakreslit. Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd. A to s různou mírou zadrátovanosti (minimálně závislost na kterékoli komponentě znamená závislost na systemd a z něho závislosti na některých součástech, třeba journald je typický příklad), to jako považujete za čistý init systém, jo?

To jsou ale samostatne pouzitelne nastroje. Samostatne binarky, chcete-li si to namalovat. A ze ty binarky zavisi na nejake knihovne? No to uz tak milej pane chodi... kazda binarka ma svoje zavislosti. Samotny init na nich nezavisi, pouze jej funkcne obohacuji - ale jde fungovat i bez nich.

A zrovna journald je typicky prikad toho, jak pricetne delat logovani v 21. stoleti. Jiste, porad muzete mit marast oddelenych textaku, kde si pak nejaky chytrak usmysli, ze prida svuj vlastni - oddeleny, ale jaksi opomene jej rotovat... a vyrobi vam tikajici bombicku :-) Typicky hate pochazi od lidi, kteri journald vlastne neumi pouzivat...

1. Nejsou to samostatně použitelné nástroje.
2. Jasně, například tranzientní závislost NTP na logovacím daemonu, je naprosto normální
3. journald je příčetné logování? Tak to toho asi moc nespravujete. To je vhodné tak možná na desktop.

4. 11. 2025, 10:19 editováno autorem komentáře

Ano, chod NTP chcete logovat. Minimalne situace, kdy nefunguje jak ma. Co je na tom divneho? :-) Vy snad (ne)fungovani NTP nelogujete?

A samozrejme, ze logovani pres journalctl se pouziva lepe, nez ruzna "grep" alchymie nad po disku roztahanymi textaky. Uz jen takove malickosti journalctl jako --since, --until, --unit...

To je asi jako vysvětlovat opici teorii relativity. Vy prostě evidentně nic nespravujete a prostě nevíte. Víte, jak se v linuxu loguje? No, evidentně nevíte. `--since`, `--until` atd. to je fakt raketová věda. Co je proti tomu například různá retence logů dle aplikace? Výsledek journald je, že se stejně nepoužívá a přeposílá se to do souborů, nebo rovnou na nějaký stack , ale s journald nikdo přímo nepracuje a je to jen trpěná komponenta, která nejde oddělat.

Ono jsou tam i dalsi veci, jako treba integrita logu. Aneb jak u toho "tradicniho" syslogu zabezpecite, ze se v tom nahodou nekdo nepohrabal? ;-) Ono je tak tezky ten textak zmenit, a tim treba i skryt nejakou nezadouci aktivitu, ze? (jiste, to jde vyresit tim, ze log poslu i jinam - ale bavime se o lokalnim storage) Napriklad instantne komprimovany zapis logu je take praktictejsi, nez textakovy tradicni syslog - kde kdyz se neco necekane zblazni, tak ten diskovy prostor mizi pomerne rychle, ze? :-) Ale zda se, ze to jste pane "zkuseny" nikdy nezazil...

Ale vase tvrzeni, ze nikdo s tim nepracuje je proste blabol. Nepracuji s tim predevsim hateri systemd, kteri se proste odmitaji ucit neco noveho, protoze jsou prece dvacet let zvykli neco delat...

Pan zkušený ví, že na logy je oddělený volume a když se něco zblázní, tak tomu ani komprese nepomůže, jen to oddálí. A taky ví, že lokálně uložené logy se tailují a zpracovávají jinde (zejména pro security). A co se učení nových věcí týče, tak s tím problém absolutně nemám, ale když je něco k ničemu, tak tomu nic nepomůže. Krásný rozdíl je mezi servicema v systemd (dobré) a logováním v systemd (na prd).

Ne nebavime. Jakmile chcete integritu, autenticitu a podobne vlastnosti logu, typicky logujete ihned pryc. Casto neverite ani lokalnimu zdroji dns, ntp apod. Pouze chcete, aby jadro co nejrychleji a hlavne bez zbytecnych prostredniku, informace poslalo pryc. Lokalni zaznamy at uz s souborech, nebo v db pak slouzi maximalne jako honeypot.
Naopak pro bezne stroje napr. pro uzivatele, je podle mne log soubor diky sve jednoduchosti a beznym vlastnostem (napr. offline cteni) rozumnejsi volba.

Journald ale nejakou integritu resi. Nebo snad chcete zpochybnit Forward Secure Sealing? Copak v nem vidite za problem?

> Napriklad instantne komprimovany zapis logu je take praktictejsi

Já jsem tady a na AbcL dělal benchmarky velikosti journalu vs. ekvivalentního syslogu (textového) za stejný čas, a journal z toho vždy vyšel mnohonásobně hůře - neuvěřitelně větší. A následně to další uživatelé reprodukovali - v jedné diskuzi dokonce i vy osobně. (příklad takové analýzy) Nerozumím tedy, proč to tu znovu píšete - nebo se s novou verzí systemd/journald něco změnilo a už to komprimuje? Výše uvedený test je na Debianu Trixie (v době psaní komentáře asi měsíc před vydáním), čili dosti nové verze.

Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat, ktere mj. umoznuji jednoznacnou identifikaci puvodce dane zpravy. A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu... pripadne u starsich instalaci zrevidovat, jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje.

> Kdyz ono je to tezke - vam prijde jako "problem" ukladani metadat

Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.

> A jinak pomoci konfiguracni volby Compress muzete i upravovat parametry/chovani te komprese, pokud se vam nelibi default, obcas to chce juknout do manualu...

Tak se pochlubte, jakých výsledků dosahujete vy. Třeba je to opravdu jen mojí/naší neschopností / výrazně neoptimálním defaultním nastavením.

> jestli se tam z minulosti neprenesl nejaky artefakt, co stav spise zhorsuje

Šlo o čerstvou instalaci Debianu Trixie (tehdy verze po prvním zmražení).

Ta metadata jsou ale podezřele velká, nebo jich je zbytečně mnoho, nebo jsou nevhodně uložena.

Můžu se jen zeptat, proč to vlastně řešíš?

Ptám se proto, že disky na serverech jsou tak velké, že řešit kolik má log (typicky 30 dnů) jsem za 20 let nemusel vlastně nikdy. A kdykoliv někdo chtěl nebo potřeboval ukládat logy navždy, tak přinesl tak velké pole, že mi z toho spadla brada.

A ta poznámka o metadatech mi připomněla situaci, kdy se někdo divil, proč ten "můj" postgresql má tak velká data a že se to dá určitě uložit úsporněji. No .... ano, pokud si napíšu vlastní storage, do kterého budu ukládat pouze golang struct v gob, tak to bude skutečně několika násobně menší, ale otázkou je, jestli chci pro každý projekt psát vlastní storage (nechci) a nebo jestli prostě použiju (ano!) univerzální datový typ BYTEA, případně to rozhodím do sloupců. A u mne vyhrává stále to druhé. A pokud vím, že těch logů bude opravdu hodně, tak to naházím do PG prostě ve standardních gobech do bytea a napíšu další program, který to potom postupně rozhodí do dalších tabulek.

Až budu psát simulátor galaxie, tak záznamy o těch 100mld hvězd určitě do PostgreSQL ukládat nebudu, ale na obyčejná data to zatím bohatě stačí.

"Ptám se proto, že disky na serverech jsou tak velké, že řešit kolik má log "

Spousta serveru zadny disk nema, a loguje treba na nejaky SDcko, ktery je jednak maly, druhak se zbytecne osoupava.

Spousta serveru zadny disk nema, a loguje treba na nejaky SDcko, ktery je jednak maly, druhak se zbytecne osoupava.

Tohle někdo viděl v praxi? Jednak disky jsou doslova spotřební zboží, takže výměna vadných disků je od určitého počtu práce na plný úvazek a od doby přechodu na DC Intel SSD (od roku 2014 a tehdy P3500) je jejich životnost zatím mnohem lepší, než u rotačních disků.

> Můžu se jen zeptat, proč to vlastně řešíš?

Velikost mě zas tak netrápí, ale když někdo tvrdí, že je journal komprimovaný a menší, tak to uvádím na pravou míru.

Co mi vadí nejvíc je UX:

- rychlost výpisu (journalctl | grep trvá také řádově déle než textový soubor, a to i když je textový soubor zagzipovaný - jo, možná má journal nějaké interní rychlejší vyhledávání, snad)
- otevřu si journal, otevře se v lessu, zmáčknu end, a to nejde, protože to generuje výpis viz výše a to trvá. Takže musím rovnou při otevírání journalu dávat -n 2000, --since nebo něco a doufat že to bude stačit.
- když mám ten otevřený journal v lessu a zmáčknu end, tak se nedonačtou nové věci (protože to journal už vypsal a skončil a už si povídám jenom s pagerem). Oproti tomu když v lessu mám otevřený soubor a dám end, tak ho to přenačte a vidím nové položky. Obdobně lze v lessu zmáčknout "F" a přepne se jakoby do režimu "tail -f". Takže jediná možnost jak vidět nové věci je journalctl -f, ale v tom logicky zase nejde scrollovat
- nejde nastavit různá doba uložení různým věcem jinak než že použiju úplně oddělené journaly
- nejde smazat specificky jednu unitu co se zbláznila a zaplevelila logy a zbytek nechat
- a už vůbec nejde u zblázněné unity smazat zprávy odpovídající regexu a zbytek nechat

Ok, já používám automaticky -f s kombinací určitého počtu -u, takže na pager nenarážím.

Pokud se nějaká služba zblázní, tak to vidím v monitoringu a ne až v logu.

Pri mesicni retenci... takovy bezny server (nginx/php/ma­ria/postfix..­.), na ktery i chodej lidi.

$ du -sh /var/log/journal/
1.3G    /var/log/journal/

neprijde mi to jako cislo, ktere by mi melo nejak zvlast trhat zily :-) Zijeme v 21. stoleti, fakt neprovozuju masiny s 200MB harddisky.
Metadata osobne za dulezita povazuju - vzhledem k fungovani tradicniho syslogu, kdy "pachatel" nemus byt nutne na prvni pohled zrejmy a kdy vzhledem k "primitivnosti" samotneho protokolu se obcas sovy nemusi jevit tim, cim jsou, zeano...

Škoda, že jste jako všichni hujeři opominul fakt, že jednodušší nástroje, které třeba naprosto stačí často není zdaleka tolik třeba umět používat. Když vám dám do ruky bagr, taky ho dost pravděpodobně (minimálně statisticky pravděpodobně) nebudete umět používat narozdíl od lopaty, kterou bravůrně zvládnete (přinejhorším po krátké instruktáži) za pět minut.

A celé to opravdu neznamená, že je horší bagr nebo lopata. Jsou to dva nástroje pro jiné případy užití. Bez kontextu tvrdit, že jedno je lepší než druhé je nesmysl.

A tak jiste, nekdo radsi bude tyden kopat zaklady lopatou... jen aby se nemusel ucit s bagrem a mohl nadavat na pokrok :-)

A zase ty tvoje demagogie. Mimochodem, ty používáš bagr pokaždé, když potřebuješ přehrabat dětem pískoviště?

Za prvé, není to tak dávno, co jsem se účastnil kopání základů lopatou a krumpáčem, protože bagr v daném místě by byl nesmysl. Zhodnotili jsme, že lopatou to prostě bude rychleji.

Za druhé, nikdo tu neříká, že všude bude používat lopatu a nikde bagr. Píše, že občas se hodí lopata, občas se hodí bagr.

Za třetí, pokud něco lopatou vykopu rychleji, než se naučím s bagrem, má cenu učit se s bagrem?

Za čtvrté, pořizovací náklady - slušný bagr je trošku dražší a náročnější na provoz nez lopata.

Za páté, journald je skutečně trpěná a útrpná komponenta. To, co mám během pár minut hotové nad textovým souborem s logy, to s journald hledám násobně déle. A to už si konečně pamatuji alespoň základní parametry.

A vy pouzivate na detske piskoviste lopatu? :-)

Ano, dava se smysl ucit nove veci - i kdyz tim prvotne treba stravim vic casu. Nabyta zkusenost se typicky hodi vickrat - a nemusim nutne vedet dopredu, kdy ji budu (opet) potrebovat.

Bagr si porizovat nemusite, ono v dnesni dobe neni zas takova magie si jej nekde proste pujcit.

Ze vam veci s journald trvaji dele je spis obraz vasi nesikovnosti :D

Jak pouzit lopatu
https://youtu.be/-SQAwVHUERk?si=0hFBsNaB7SRk9EEQ&t=64

> Jinak součástí systemd jsou: journald, libudev, localed, logind, hostnamed, homed, networkd, resolved, systemd-boot, systemd-bsod, systemd-nspawn, timedated, timesyncd, tmpfiles, udevd.

Větší polovinu z uvedeného nepoužívám ani nemám nainstalovánu, u některých věcí dokonce ani nevím, k čemu slouží. Pro věci jako networkd, resolved, timedated jsou naprosto zjevné náhrady ze kterých si můžete vybrat (jakýkoli network manager preferujete, jakýkoli DNS server preferujete, jakýkoli NTP klient preferujete).

Co má znamenat v daném kontextu to "core"?

Co má znamenat v daném kontextu to "core"?

FreeBSD tým řeší kromě samotného kernelu taky vlastní programy (něco jako coreutils). Takže při instalaci lze zvolit kernel, base (core), porty. kernel+base je vlastně nejmenší možná instalace a i bez dalších balíčků (pkg nebo porty) je tam toho vlastně dost, takže na tom lze postavit samostatný server (bez dalších balíčků).

Tak samozřejmě - jádro je jen část (ta menší) operačního systému. A FreeBSD je, na rozdíl od Linuxu, operační systém. Proto to "core" nedává v tomto kontextu smysl - prostě jste si nainstaloval FreeBSD a nakonfiguroval jste si v něm server. ;)

Jenže tady je podstatné to, že o kernel a base systém se stará stejný tým a je to na tom opravdu vidět. Podpora pro jaily je ve všech systémových příkazech, stačí dát parametr -j a už konfigurujete kontejner. A asi nejhezčí případ je soft-updates pro UFS2 v době, kdy ext2 se rozhodovala, jestli bude mít journal, tak UFS2 mělo snapshoty (i když omezený počet) a journal se obešel právě jiným způsobem update kritických struktur ve fs. A tenhle jeden FS jim vydržel vlastně až do nástupu ZFS.

V systemd to funguje podobně, stačí dát některým příkazům parametr -M a už nastavujete nspawn. Ale už vidím, jak někdo "nutí" implementaci -M i do dalších programů v repositáři. ;-) (To jen takové rýpnutí.)

Takže ona "konfigurace" serveru ve FreeBSD se vlastně rovná jen jeho instalace. A pokud je to pro můj program, tak jedna binárka, konfig a služba a je hotovo.

Tohle jsem na linuxu nikdy nezažil. Jasně, u systemd stačí binárka, unita, konfig, ale potom někdo přijde s tím, že chce docker, takže dockerfile, potom někdo LXC a tak dále.

Jako já jsem psal, že cron rozhodně není dokonalý. Ne vlastně je spíš na kopanec. Ale třeba není to tak dávno, co jsem potřeboval dynamicky generované crontaby dostat do k8s a cronjoby na to nebyly vhodné (kvůli té appce, to nebudu rozebírat) a teď mi poraďte s timerem...
Jako fakt bych radši novou reimplementaci cronu, spíš nějaký svébytný anacron, ale timer to není.

a teď mi poraďte s timerem...

Já nevím, co konkrétně řešíte, ale generovat konfigurační soubory pro timer jde snadno.

Ale musíte tam mít puštěný celý systemd a to, že byste si konfiguraci přimountoval z volume, tak to asi moc nepůjde.

Ale musíte tam mít puštěný celý systemd a to, že byste si konfiguraci přimountoval z volume, tak to asi moc nepůjde.

Já nevím, co myslíte tím celý. Systemd v nspawn je typicky jen a pouze pid1, který spouští služby. Nic dalšího tam neběží, protože je to jaksi kontejner. Takže v případě mých nspawn kontejnerů jeho vnitřní systemd spustí jenom ssh a třeba nginx. A tím jeho role končí.

A pokud v kontejneru potřebujete kromě jednoho procesu té služby, pro který je ten kontejner vytvářen i něco jako cron, tak se bez nějakého dalšího managera stejně neobejdete. Tuším, že docker má nějakou možnost správy interních procesů, ale víc o tom nevím. Já provozuju pouze nspawn a jaily (na freebsd).

Nevím, tohle jsem nezkoušel, ale s cronem prostě v kontejneru s aplikací přidám a pustím crond (a kdyby to nebyl cron, tak nějaký soft, který by to uměl), není potřeba nic víc.

A to ma nejake prakticke uziti a nebo jde jen o vystrelek z kategorie "protoze muzu"

Já teda nevím, na co přesně reaguješ, ale já mám poměrně jednoduchý default. Nastavit maximum, co umí HW. Takže pokud každá integrovaná zvukovka (čip stojí méně než dolar) na desce umí automaticky 192kHz/24b, tak nastavím 192/24 a tak nějak počítám s tím, že to prostě bude fungovat. A s příchodem PulseAudio se vrátily nadávky na netopýry apod. Já si prostě zjednodušuju život nastavením maxima a pokud někdo chce zkoumat, co kde zrovna slyší a vidí a nastavuje si monitor třeba na 6b místo 10b, tak je to jeho boj, ale zase u toho nemusí nadávat lidem, kteří nastaví všude max.

A když už mám doma Marantz a Bowers and Wilkins, tak prostě chci, aby nic, byť třeba jen teoreticky, neomezovalo data po cestě. A jestli těch 80kHz slyším nebo neslyším, tak do toho nikomu nic není.

A tohle je dlouhodobá zkušenost. Ze všech foťáků ukládám raw a někdy jsem moc rád, že tam ta data ze všech těch pixelů jsou (znám lidi, kteří mají i na zrcadlovce rovnou nastaveno ukládat pouze jpeg). Proč bych se měl zbavovat byť třeba zrovna nepotřebné informace jsem vlastně nikdy nepochopil. Pokud ta data nikdy nebudu potřebovat, tak je to vlastně jedno, ale naopak, když je budu potřebovat, tak tam prostě jsou.

A tak pri zbeznem pohledu do dokumentace pipewire nastavit 192kHz/24b v pohode zvladne. Ale feedback vam neposkytnu, zas takovy audiofil nejsem :-)

No ono to papírově zvládalo i Pulse, ale potom tam nastoupil resampler, který řekl ne (co se týče nároků na CPU). Takže i na prvním Ryzenu nešlo dělat v Pulse to, co uměla levou zadní Soundblaster Audigy (která měla HW audio mixer, takže resampler nebyl potřeba). Takže jsem to vyřešil po svém, na stole mám mix pult, do kterého hraje několik zvukovek podle toho, co zrovna dělám (jedna na hry do sluchátek, druhá na HiFi a integrovaná na desce pro zbytek). Dneska signálové procesory sice umí hromadu vstupů, ale tak na deskách máme obyčejný DA "kodek" (nevím, proč se tomu tak říká, je to prostě simple DA převodník), který chce data v přesné podobě.

Ok, takze jste otrok minulosti. Inu taky filozofie... :)

Ok, takze jste otrok minulosti.

V čem přesně?

Tou aplikaci zaveru z pulseaudio na wireplumper ;-)

Žádný závěr nedělám. Ty ses jenom podíval do dokumentace a tam jsi něco našel, ale nenapsal jsi, že jsi to vyzkoušel. Stačí vytáhnout audacity a osciloskop a otestovat to. Jestli někdy v geologicky dohledné době budu mít linux na desktopu, tak to samozřejmě otestuju. Snad se mezitím ze Slunce nestane červený obr, ale tak to bych ještě stihnout mohl.