On 12/12/2025 21:46, Greg Wooledge wrote:
The *DEFAULT* logging under systemd is the binary journal which can only be read by systemd's command set. *BY DEFAULT* you have no human-readable log files, meaning you cannot read them with a comfortable and familiar command line interface, nor can you read them by mounting the (partially failed?) disk in a different system for post mortem analysis, and so on.
I admit I have not had an accident requiring real postmortem analysis so far, but is it a real problem? After all, "a different system" may be booted from a live image or running in a VM, or it may be just a remote host with journalctl binary.
Actual use case caused this thread is still not clear for me. I suspect a better approach may exist, e.g. continuous logging to a remote host or selective exporting of journal to desired (e.g. syslog-like text) format filtering by timestamp or by other criteria.
My impression is that journald makes debugging easier in most cases due to more complete and detailed messages. Perhaps an exception is busybox from initramfs recovery shell.
P.S. On a really different system, getting files from a disk with ext4/btrfs/zfs file system and perhaps LUKS/LVM/dmraid layers may be not so trivial task to bother concerning journalctl.
