4 ms·

You do still _use_ rsyslogd if you enable it. journald is fundamental to some core systemd functionality. Of course you can't get rid of it.

by ibotty 7y ago

newnewpdro 7y ago
Right, which just turns rsyslogd into another consumer of the journal data analogous to `journalctl --follow --all`. You still have all the overhead (and surface area) of journald being in the loop of everything logged. Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged. If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
- bonzini 7y ago
  > If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1. I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
- ibotty 7y ago
  It also gets back logs from journald! How do you envision `systemctl status $unit` to show the last logs if they are in some random log file?
  - newnewpdro 7y ago
    First of all, no, systemd as in PID1 does not get logs back from journald. The systemctl command is using the sd-journal API to do that directly from the journal files. Secondly, I don't, I expect the recent logs portion of `systemctl status $unit` to be suppressed when journald isn't present. Note that journal-caused slowness of that very command is a common complaint aimed at journald contributing to people wanting to remove it!
  - kungtotte 7y ago
    With runit, for example, logs are put in a canonical per-service directory. E.g. `service_directory/service/logs` Seems like a trivial way to solve it...
    - ibotty 7y ago
      Yes, of course that's possible. But that's no generic syslog daemon either.

You do still _use_ rsyslogd if you enable it. journald is fundamental to some core systemd functionality. Of course you can't get rid of it.

by ibotty 7y ago

You do still _use_ rsyslogd if you enable it. journald is fundamental to some core systemd functionality. Of course you can't get rid of it.

newnewpdro 7y ago

Right, which just turns rsyslogd into another consumer of the journal data analogous to `journalctl --follow --all`. You still have all the overhead (and surface area) of journald being in the loop of everything logged. Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged. If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.

bonzini 7y ago
> If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1. I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
ibotty 7y ago
It also gets back logs from journald! How do you envision `systemctl status $unit` to show the last logs if they are in some random log file?
- newnewpdro 7y ago
  First of all, no, systemd as in PID1 does not get logs back from journald. The systemctl command is using the sd-journal API to do that directly from the journal files. Secondly, I don't, I expect the recent logs portion of `systemctl status $unit` to be suppressed when journald isn't present. Note that journal-caused slowness of that very command is a common complaint aimed at journald contributing to people wanting to remove it!
- kungtotte 7y ago
  With runit, for example, logs are put in a canonical per-service directory. E.g. `service_directory/service/logs` Seems like a trivial way to solve it...
  - ibotty 7y ago
    Yes, of course that's possible. But that's no generic syslog daemon either.