5 ms·

I'd rather see init's problems fixed (i.e. start services in parallel), but systemd is far better than upstart (edit: got it to load at last, I see it's not by

I'd rather see init's problems fixed (i.e. start services in parallel), but systemd is far better than upstart (edit: got it to load at last, I see it's not by upstart fans, so ignore that last part). That said, a lot of systemd seems like a really stupid idea to me, e.g. binary logs, the massively increased SPOF size, and the "do everything" mentality. Unfortunately, I don't know of any distros that aren't using it now (edit: I didn't even realise Slackware was still a thing...), and upstart is even more of a joke than systemd.

crashandburn4 13y ago
I've got to agree with a lot of your points here, to paraphrase churchill, systemd is the worst system management daemon system that we have, except for all those other ones that have been tried from time to time. (this sounds a little harsh to the other ones, but I find systemd intuitive from a user-facing perspective even if it does have a lot of inelegance under the hood) [0] http://wais.stanford.edu/Democracy/democracy_DemocracyAndChurchill(090503).html http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...
quasque 13y ago
What's wrong with binary logs? Seems like an improvement, given how they can be cryptographically 'sealed' to help tamper detection, and have indexes built in [1]. [1] http://www.freedesktop.org/wiki/Software/systemd/journal-files/ http://www.freedesktop.org/wiki/Software/systemd/journal-fil...
- icebraining 13y ago
  Sealing sounds interesting, but that page doesn't explain why can't plain-text logs be sealed.
- mrweasel 13y ago
  Binary logs are pretty annoying because your standard tools for searching through them no longer works. tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.
  - vidarh 13y ago
    Which only means that you need to pipe the output of journalctl to your standard tools. It hardly renders any of you tools useless.
    - blueskin_ 13y ago
      Not all tools operate on stdin. For that matter, this doesn't fix the millions of people and organisations who will have custom tools and processes. All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
      - Tuna-Fish 13y ago
        > All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format. Actually, they won't. Because journald has the relevant functionality built-in -- that is, it can automatically stream out the logs in any format you choose, including ones understood by rsyslogd, and if you really just don't like journald, you can just turn off it's storage and turn it into nothing but a shim.
      - vidarh 13y ago
        > Not all tools operate on stdin. So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo. > All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format. For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that. Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information. Regarding the last point, here's an example of an entry from journalctl -o json-pretty: { "__CURSOR" : "s=56750fa36ad94eb99c00e7fd6854c400;i=2;b=2f533403d7a041e7a389e3a7090942de;m=172e6e4;t=4f7c809a2f61d;x=79a98b8a5116658a", "_SYSTEMD_CGROUP" : "/system/cron.service", "_SYSTEMD_UNIT" : "cron.service", "SYSLOG_FACILITY" : "10", "SYSLOG_IDENTIFIER" : "CRON", "_CMDLINE" : "/USR/SBIN/CRON", "MESSAGE" : "pam_unix(cron:session): session closed for user root", "SYSLOG_PID" : "2398", "_PID" : "2398", "_SOURCE_REALTIME_TIMESTAMP" : "1398345421294046" }

crashandburn4 13y ago

I've got to agree with a lot of your points here, to paraphrase churchill, systemd is the worst system management daemon system that we have, except for all those other ones that have been tried from time to time. (this sounds a little harsh to the other ones, but I find systemd intuitive from a user-facing perspective even if it does have a lot of inelegance under the hood) [0] http://wais.stanford.edu/Democracy/democracy_DemocracyAndChurchill(090503).html http://wais.stanford.edu/Democracy/democracy_DemocracyAndChu...

quasque 13y ago

What's wrong with binary logs? Seems like an improvement, given how they can be cryptographically 'sealed' to help tamper detection, and have indexes built in [1]. [1] http://www.freedesktop.org/wiki/Software/systemd/journal-files/ http://www.freedesktop.org/wiki/Software/systemd/journal-fil...

icebraining 13y ago
Sealing sounds interesting, but that page doesn't explain why can't plain-text logs be sealed.
mrweasel 13y ago
Binary logs are pretty annoying because your standard tools for searching through them no longer works. tail, less, grep, wc and similar tools are rendered useless. Newer tools like logstash or Splunk are also going to have issues reading your binary logs. It's not really a wise thing to break the tools that most people use every day, it's just going to make them hate you.
- vidarh 13y ago
  Which only means that you need to pipe the output of journalctl to your standard tools. It hardly renders any of you tools useless.
  - blueskin_ 13y ago
    Not all tools operate on stdin. For that matter, this doesn't fix the millions of people and organisations who will have custom tools and processes. All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format.
    - Tuna-Fish 13y ago
      > All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format. Actually, they won't. Because journald has the relevant functionality built-in -- that is, it can automatically stream out the logs in any format you choose, including ones understood by rsyslogd, and if you really just don't like journald, you can just turn off it's storage and turn it into nothing but a shim.
    - vidarh 13y ago
      > Not all tools operate on stdin. So pipe it to a file and operate on that. Or give the broken tool /dev/stdin as its filename. Or give it a fifo as a filename and "journalctl | /path/to/fifo. > All the binary logs are going to do is make people have a cronjob to extract them regularly into a readable format. For those who insist on that, yes. Most of them will presumably have logrotate set up anyway, so it's hardly more complexity. Or you can run a syslog, and trivially set up systemd to forward the log entries to that. Meanwhile the rest of us will enjoy the ability to do things like specify a start and end time with command line switches when trying to find stuff in the log, filter by priority, filter by user, filter by pid. seeing only data since last boot, get the journal as JSON instead of having to rely on brittle text parsing of entries that contains less information. Regarding the last point, here's an example of an entry from journalctl -o json-pretty: { "__CURSOR" : "s=56750fa36ad94eb99c00e7fd6854c400;i=2;b=2f533403d7a041e7a389e3a7090942de;m=172e6e4;t=4f7c809a2f61d;x=79a98b8a5116658a", "_SYSTEMD_CGROUP" : "/system/cron.service", "_SYSTEMD_UNIT" : "cron.service", "SYSLOG_FACILITY" : "10", "SYSLOG_IDENTIFIER" : "CRON", "_CMDLINE" : "/USR/SBIN/CRON", "MESSAGE" : "pam_unix(cron:session): session closed for user root", "SYSLOG_PID" : "2398", "_PID" : "2398", "_SOURCE_REALTIME_TIMESTAMP" : "1398345421294046" }