Názor k článku
Systemd v roce 2022 povyrostlo na 1,7 miliónu řádků kódu od Uncaught ReferenceError: - ad 1) escapování má vždy dvě strany, při...

ad 1) escapování má vždy dvě strany, při uložení nechceme rozbít formát dat, při čtení nechceme interpretovat něco, co nám může udělat paseku. A jak prosímtě escapuješ do textového logu? Vždyť to nemá žádná pravidla. journald umí vracet strukturovaný výstup (json např.), kde již je vše řádně escapované.

ad 2) ty nuly tam jsou uloženy dopředu jako prostor, kam se zapisují další logy. Hard reset je tvůj častý případ? Journald primárně data drží v paměti a v pravidelných intervalech syncuje na disk. Pokud chceš dobře fungovat s hard resety, asi bych zvolil úplně jinou technologii na zápis logů. Ano, můžeš si počítat vlastní checksum, ale tady se bavíme o univerzální logovací službě.

ad 3) v jaké konfiguraci? Výchozí nastavení v distribucích je tak trochu hodně univerzální a o nic moc se nesnaží, výhoda journald je jeho dokumentace a možnost přízpůsobení.

Zkoumat logy přímo na serveru je něco, co se spusty let v mém vesmíru nedělá, logy sbíráme a replikujeme na centrální server, snažíme se prokazatelně sesbírat a přenést všechny (to journald umí pěkně), poté se indexují a dělají nad tím další operace. Jde o to, že přístup na produkční servery pod rootem má málokdo, dělat si tam nějaký streaming logů do konzole je pro mě tak trochu mimo.

Podle toho, co tady píšeš, tak máš nějaké malé přenosné linux stanice, ty mají připojený nějaký HW, s kterými komunikují a to logují. To vysvětluje ty časté hard resety, na to journald zrovna není přeborník a klidně použij něco jiného, těžko víme jak to máš, začal jsi univerzální kritikou, tu jsme se snažili mírnit, teď to vypadá, že v tvém konkrétním případě journald není vhodný, skvělé si to uvědomit a najít vhodnější řešení.