3 ms·

Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somew

Well, "monolithic" isn't very clearly defined, either way. There's multiple interpretations, but systemd does fall under tight coupling. Its modularity is somewhat arbitrary. A lot of auxiliary daemons can be configured out of the build, but some others like generators and most damningly journald, cannot. Yes, you can run regular syslogd and crond implementations beside systemd's journald and timer units. To be honest, it would be pretty ridiculous if you couldn't, and it's not much of a consolation. Although journald can be effectively disabled by forwarding to syslog (however, PID1 itself no longer supports syslog as a target), the systemd developers do want it to be the primary syslog mechanism on a Linux system, and are pushing it as such. Yet due to choosing to use a binary format similar to a RDBMS, but without the transaction consistency of an actual RDBMS, it's prone to unnecessary corruption. This was deemed not to be an issue, apparently: https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116 Then you have an (optionally network-enabled) system logging service that stays resident without being used, a potential attack vector and really just a huge, completely unnecessary sink to proxy your actual syslogd of choice to.

evol262 12y ago
You're damning journald for things syslogd doesn't do either. Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted). Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing. Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger
- vezzy-fnord 12y ago
  From my experiences with Fedora 20, journal corruptions happen in seemingly random cases. Not on any system crashes either, but just clean reboots. As well as other general systemd issues occasionally, including message bus queue freezes. The plaintext medium is more reliable, largely because recovery can be performed with any generic tools that operate on text streams. Third-party journal readers, on the other hand, are discouraged.

evol262 12y ago

You're damning journald for things syslogd doesn't do either. Syslog is not reliable. Syslog is incredibly falsifiable (journald is not). Syslog does not handle system crashes well either (pretty much the case where journald gets corrupted). Syslog also doesn't capture application logs. Syslog does not hand over from dracut. Syslog guarantees nothing. Don't present it as a step backwards when it's a step forwards, albeit with some warts. Even in its worst case, journald still provides more functionality and more security than syslog, and you can still use your normal syslogger

vezzy-fnord 12y ago
From my experiences with Fedora 20, journal corruptions happen in seemingly random cases. Not on any system crashes either, but just clean reboots. As well as other general systemd issues occasionally, including message bus queue freezes. The plaintext medium is more reliable, largely because recovery can be performed with any generic tools that operate on text streams. Third-party journal readers, on the other hand, are discouraged.