> Any discussion about this should be anchored with an answer to the questions I asked earlier: What functionality do you think systemd should not have that it has today? What is a better way of achieving the benefits provided by that functionality?
I already replied to that.
> How do you recommend capturing and logging program output, if not by having the supervisor do it? (And why is that approach preferable?)
Supervisor is in appropriate place only for substituting STDOUT and STDERR
descriptors at the daemon's start, but once that is done, the descriptors are
easily transferrable to logging daemon. Obviously, the logging daemon should
understand that, so rsyslog would need a plugin to accept those descriptors,
or a generic intermediate daemon that reads all the output and sends it
further to syslog would be needed, but that's it. There's literally no
benefit in coupling log collector with zombie reaper as tightly as in systemd.
> The journal is an integrated part of the systemd toolkit, and that's a good thing because it enables useful capabilities like capturing stdout
...which is easily achievable without coupling...
> and good user experiences like `systemctl status`.
...which is useless anyway, as I said in my earlier post. Oh, but this "good
user experience" is indeed really excellent, because when I start a daemon and
it dies, `systemctl start' does not print the information that daemon failed
to start nor the daemon's initial logs. I get nothing and I don't know
that the daemon died. Indeed, great user experience. Or updating unit files,
again, great experience when the unit file acts in exactly the same way as
previously, because I forgot to reload systemd and it didn't inform me to do
so. Or systemd automatically chopping log output to my terminal. Or awful
command line syntax of journalctl. Top notch user experience indeed!
> But you don't have to interact with it. If you prefer the syslog toolchain instead, then redirect the journal to syslog via ForwardToSyslog=yes in journald.conf.
So this tight coupling is good, because it gives me nothing useful over not
coupled architecture and I can easily work around this coupling? This is what
you're trying to say?
> The journal still adds value with this approach because it captures logs that syslog can't (and without kludges like `logrotate` and `logger`).
First, syslog can capture this output. It's not impossible and it's not even
difficult.
Second, these "kludges" that worked well for decades are replaced with (a)
brittle disk format that breaks apart on system crash, (b) lack of control
over how long the logs are kept, and (c) lack of remote log collection.
> Is there another IPC framework you think systemd should have integrated with instead?
You're asking wrong question. It's not that systemd should not integrate
with D-Bus, it's that it should not swallow it.
And now I'll ask once again: what is the so important reason for systemd to
provide QR code generator and task scheduler?