Rick Moen <rick@linuxmafia.com> writes:
Quoting Mark Trickett (marktrickett@gmail.com):
The fact it does binary logs is a _very_ _major_ defect in my opinion and experience.
For completeness, I'll note that it's pretty easy to disable the handoff of logging information to systemd-journald and substitute a handoff to rsyslog or syslog-ng, instead. So, for example, the Debian package for systemd defaults to rsyslog as system logger.
Please provide details on this. Debian rsyslog is configured to read from /run/systemd/journal/syslog instead of /dev/log by default, if it detects systemd is running. AFAIK it is *not* trivially possible to opt out of journald; You can have either journald alone, or syslog chained off journald. busybox-syslogd in debian 8 does not work at all while journald is in place, because it (debian busybox) is compiled without CONFIG_SYSLOGD, and without that there is no way to tell busybox-syslogd to read from /run/systemd/journal/syslog, so syslogd effectively receives no logs.
echo -e 'Package: systemd\nPin: origin ""\nPin-Priority: -1' > /etc/apt/preferences.d/systemd echo -e '\n\nPackage: *systemd*\nPin: origin ""\nPin-Priority: -1' >> /etc/apt/preferences.d/systemd
Suggest printf(1); echo -e breaks if dash is your login shell.
A few things such as bsdutils and util-linux have started to depend on libsystemd0, but that seems harmless.
Agree. I think that is primarily to handle socket-based startup & logging to journald instead of /dev/log. In such code I have looked at, it is typically laid out thusly: if /run/systemd exists, [new behaviour] otherwise [traditional behaviour]