4 ms·
> Parsing all of that mess is extremely “hacky”, with tons of regexes trying to account for all vendor quirks. Whilst that's possibly true, at least you/we hav
by smetj 5y ago
> Parsing all of that mess is extremely “hacky”, with tons of regexes trying to account for all vendor quirks.
Whilst that's possibly true, at least you/we have the possibility to do so.
- viraptor 5y agoWhat do you mean? You have this possibility with virtually every logs system. (On Linux anyway) Some of them just make it much easier.
- jandrese 5y agoTry doing it with the Windows Event Viewer. SystemD's built in log thing at least has a text dump feature, but god help you if the database gets corrupted.
- viraptor 5y agoThat's why I said for Linux. Journald does not really have a database as such - it has index + sequential logs data. You can run the data through strings (unless you enabled compression) to get your data in emergency. You'd lose as much data from plaintext log corruption.
- pengaru 5y ago> but god help you if the database gets corrupted What is this FUD nonsense you're attempting to spread here? systemd-journald assumes journals marked as ONLINE when opened for writing are potentially corrupted, and renames them rather than attempting to write to them, which produces messages like "journal corrupt, renaming". Those renamed journals still participate in journalctl queries, the data isn't lost. It's just a bit of wasted space in the interest of not risking actually corrupting an uncleanly shutdown journal by writing to it.