5 ms·

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobo

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

plaguepilled 4y ago
I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.
- gupnop 4y ago
  There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
  - awruko 4y ago
    > indexed for quicker searching and filtering I think I am not the only one who is missing negative filters - check the log excluding audit messages.
  - UI_at_80x24 4y ago
    Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
    - fsh 4y ago
      If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
      - cesarb 4y ago
        Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).
    - deleted 4y ago
      [deleted]
  - cesarb 4y ago
    For me, the nice things about the systemd journal binary log format are: - It's immediately compressed (without having to wait for a log rotation); - It automatically rotates when a size limit is reached (no risk of filling the disk with logs); - IIRC, it's deduplicated (repeated messages use less disk space). All of these together means logs can be kept for much longer by default.
    - panick21_ 4y ago
      Overall agree. The only problem is if you have file corruption it could be a problem to parse. But I usually don't change the default.
  - denton-scratch 4y ago
    Rsyslog can be configured with a database backend, if you want to index the log fields.
denton-scratch 4y ago
> You can easily have it not produce binary logs. How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?
- WastingMyTime89 4y ago
  What does canonical log even means here? Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
  - denton-scratch 4y ago
    What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
    - ecnahc515 4y ago
      That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
      - denton-scratch 4y ago
        I wasn't aware of that. Can you make the memory usage arbitrarily small?
    - WastingMyTime89 4y ago
      Every log ever is a transcodification of a system state. What difference does it actually make that it is emitted into systemd structured format before being put into your logger? Seems like a pointless complain to me. It’s arguing for the sake of it.

You can easily have it not produce binary logs. Other software depending on Systemd isn't really Systemd responsibility. Its not systemd fault that almost nobody uses OpenRC.

plaguepilled 4y ago

I think its a bit of systemd's issue since it's attempting to cover a large range of functionality. The way it provides that functionality is important. Re: the binary logs - true, but the core point that its not text by default is still a (small) issue IMO. Not ideal default behaviour.

gupnop 4y ago
There are solid technical reasons for systemd's binary logging. The nice thing about its binary log format is that it's organised by fields which are indexed for quicker searching and filtering. It's much easier and faster to analyse these logs than the traditional text-based ones. Also, having journald authenticate the process that is sending it log entries, and the log sealing capability, are two features that can help guard against log tampering.
- awruko 4y ago
  > indexed for quicker searching and filtering I think I am not the only one who is missing negative filters - check the log excluding audit messages.
- UI_at_80x24 4y ago
  Being able to boot a server with a 'live USB image'; mount root, and inspect the logs to see what happened are not possible when you got a binary blob for a log. When things have really fucked up, you need the 'ease of access that plain-text log files provides.
  - fsh 4y ago
    If your live USB image is from this decade, it will almost certainly come with journald for reading the logs. If it doesn't, why choose such a bad live USB image?
    - cesarb 4y ago
      Just nitpicking, but AFAIK it's not journald which is used to read the logs, it's journalctl itself which directly reads the binary logs from the filesystem (and the normal filesystem ACL permissions are used to allow or deny reading the logs).
  - deleted 4y ago
    [deleted]
- cesarb 4y ago
  For me, the nice things about the systemd journal binary log format are: - It's immediately compressed (without having to wait for a log rotation); - It automatically rotates when a size limit is reached (no risk of filling the disk with logs); - IIRC, it's deduplicated (repeated messages use less disk space). All of these together means logs can be kept for much longer by default.
  - panick21_ 4y ago
    Overall agree. The only problem is if you have file corruption it could be a problem to parse. But I usually don't change the default.
- denton-scratch 4y ago
  Rsyslog can be configured with a database backend, if you want to index the log fields.

denton-scratch 4y ago

> You can easily have it not produce binary logs. How do you do that? If you want non-binary logs, you can have journald tee log records to rsyslog; but the canonical log is still the binary log. Have I missed something?

WastingMyTime89 4y ago
What does canonical log even means here? Systemd will produce logs in its own structured representation and write them straight away as plain text in the logger of your choice. For all intent and purpose, you now have text logs.
- denton-scratch 4y ago
  What I meant by "canonical" is that you can't get rid of the binary log; you can pipe it into a database, or a textfile, or /dev/null, if you want, but that database or textfile is transcoded copy of the binary log.
  - ecnahc515 4y ago
    That's not true, you can configure journald to be in-memory only in which case there's no binary log, no file. If your using systems, you can't really git rid of journald, but you can get rid of the binary logs.
    - denton-scratch 4y ago
      I wasn't aware of that. Can you make the memory usage arbitrarily small?
  - WastingMyTime89 4y ago
    Every log ever is a transcodification of a system state. What difference does it actually make that it is emitted into systemd structured format before being put into your logger? Seems like a pointless complain to me. It’s arguing for the sake of it.