3 ms·

> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really u

by kaba0 4y ago

> It produces binary logs, which might not work with your workflow and is a kind of vendor lock-in if you don't script a binary-to-text script I never really understood this point — it’s not some proprietary format that has to be reverse engineered, you quite literally has both encrypt and decrypt source code available for every single version it has been released. You can also just pipe the binary output through the provided “decrypt” tool and then further use the usual unix tools if you wish. But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before.

ayushnix 4y ago
> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before. From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong. One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).
- UI_at_80x24 4y ago
  >One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since). I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
  - ayushnix 4y ago
    > I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics. I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.
WastingMyTime89 4y ago
It’s even more difficult to understand when you consider than text files are themselves binary logs and given how many encoding they can have they are not even trivial ones. People should just call systemd logs structured rather than binary because that’s what they are. Sure it means you need a shim if you want to view them as plain text but it’s not like we are talking about some unfathomable complexity here.
ecnahc515 4y ago
And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.

by kaba0 4y ago

ayushnix 4y ago

> But let’s add the advantages of this logging: systemd can log events from the very start of the boot process, which was not possible before. From what I've seen using Alpine Linux for a few weeks on my Raspberry Pi, logs are written to /var/log/messages after the init process starts and launches the logging service. All logs before the init starts can be retrieved using dmesg? I'm not sure about this though, let me know if I'm wrong. One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since).

UI_at_80x24 4y ago
>One of the things I haven't figured out yet is if traditional logging systems can easily do advanced log filtering like showing only logs from the current boot (like -b in systemd), previous boots (-b -1), and showing logs after a specific date and time (--since). I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics.
- ayushnix 4y ago
  > I manage this with clever usage of grep. You are correct in that there isn't a single --flag that will only show me those specifics. I can grep my way through text logs as well but being able to get logs for different purposes using --flags is better user experience. I can always resort to to using grep, sed, and awk if I want to when using journald but the loss of these quality of life features make it hard for me to consider using a distro that does not have systemd.

WastingMyTime89 4y ago

It’s even more difficult to understand when you consider than text files are themselves binary logs and given how many encoding they can have they are not even trivial ones. People should just call systemd logs structured rather than binary because that’s what they are. Sure it means you need a shim if you want to view them as plain text but it’s not like we are talking about some unfathomable complexity here.

ecnahc515 4y ago

And you don't need journald to read the log files either, you can use `journalctl --file /path/to/file.journal` to read them directly via `journalctl`.