3 ms·

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provide

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea. My only issue with journald's binary log files is that they're of homebrewn custom format, that's not accessible by any standard means. Plain text files aren't directly readable by humans, too, but we have cat, less or alike tools to pass such data to terminal (sometimes an iconv is required, say, if log entries contain filenames that has characters outside of ASCII range), and those tools are available on every modern OS out there. Personally, I think, a compromise that'd satisfy me (YMMV) would be either an industry-standard log format (like, maybe, sqlite - it's fairly simple, universal and omnipresent nowadays) or, even better, storing data in text files, but having accompanying binary index and metadata ones that store non-human-readable stuff (like hash chain - bet, no sane human would ever check cryptographic log integrity by hand) and provide additional information for faster machine access. But the heck journald is a tightly-coupled part of into systemd instead of being a separate project is beyond me. I can't reject that systemd has some good things about it too, but it's too terribly monolithic and unhackable compared to mostly-scripted init systems. And such negative points easily outweigh the positive ones.

Sanddancer 12y ago
The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you can have all your tools readily available, and can additionally dump to plain text and/or email messages at the same time. As to the why for journald, it seems very much like the rest of Poettering's MO of NIH. He doesn't seem too capable of working with other project makers to get his goals handled, so just does everything himself, to the detriment of the overall community.
- ultramancool 12y ago
  It seems highly disturbing to me how much push he seems to have obtained by writing what have in my experience been complicated and crash-prone tools. Especially when such tools seem essentially in direct conflict with system philosophy. I'm just glad there are sane options available still.
- drdaeman 12y ago
  Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary. The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just provides a feature, but forces developers to think about structuring their log output in a machine-readable manner. I think that's the excuse that I believe is the journald's raison d'être and that I personally accept. Just my opinion, though.
  - jude- 12y ago
    Compatibility isn't the problem. The problem is the use of structured binary data itself for logs. Logging binary structures instead of raw text makes it very difficult to recover from crashes or misbehavior, since the logging facility (journald or otherwise) must ensure that the log's structure on disk is consistent at all times. I've seen more than my fair share of journald corrupting its own log due to unclean shutdowns. If I'm going to be grepping the journald log file anyway to reconstruct it (possible, but not easy, since journalctl is useless here), then why bother using it at all? It fails at the very task it was built for.
    - bigbugbag 12y ago
      Not sure it was built for the task we expect a log facility to fulfill. I mean the corruption issue is a built in feature of journald: https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116
    - 12y ago
kiyoto 12y ago
>Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea. I agree. There is a strong need for common interface(s), and that's a strong part of the motivation behind Fluentd/Kafka/etc. www.fluentd.org/blog/unified-logging-layer
nn3 12y ago
sqlite (or other "real databases") need a fsync for every or at least many transaction to be data safe. Without that it is far more prone to losing data than journald, because with a write ahead log the window for losing data is far bigger. And a journal that has another journal inside it would be somewhat silly. A simple write log can be done better. I don't think fsync on every log commit is a good idea. This would be more a DOS attack. That said I'm somewhat troubled by the cavalier attitude to log data safety in journald too.
- e12e 12y ago
  I have some difficulty figuring out the use-cases for journald over (some) plainish text log files. Our disks are getting faster and bigger. If you need to consolidate logs you have many options (starting with rsyslogd). If you need to log gigs of data, that can't possibly be kernel/initd logs?! And if it's application logs why not pipe it through something for indexing? By definition if i need kernel/local/init log files it's because something went very wrong: in such cases problems with clean shutdown/startup seems very likely - and in such use - cases plain text to file/serial wins hands down. I'm not against having a wrapper that magically slurps stderr/stdout to timestamped logs -- but if that can't be written cleanly with the apis we have, then surely what we need is to make the minimal improvement in our (probably kernel) api to make writing such a program a trivial exercise? Nothing I've seen of systemd has me convinced the project cares one whit about finding the simplest, least coupled solution to any problem.
ldng 12y ago
Systemd is more like busybox than sysvinit. People bitch about Systemd because they're not foul. Systemd folks (mostly Redhat) have their agenda. I don't mind that. Heck I even agree on some of it. But pushing the whole bloated thing down nearly everyone's throat disguising it as just a simple init replacement is a bit too much.

Sanddancer 12y ago

The biggest problem with dropping the syslog protocol altogether is that there's a huge amount of other stuff that speaks syslog. Things like networking gear use it for the same purposes as a normal *nix box, and getting them to switch is going to be like pulling teeth. With your particular case, I'd say you should look at rsyslog and/or syslog-ng. Both of them have backends that talk with actual databases, so you can have all your tools readily available, and can additionally dump to plain text and/or email messages at the same time. As to the why for journald, it seems very much like the rest of Poettering's MO of NIH. He doesn't seem too capable of working with other project makers to get his goals handled, so just does everything himself, to the detriment of the overall community.

ultramancool 12y ago
It seems highly disturbing to me how much push he seems to have obtained by writing what have in my experience been complicated and crash-prone tools. Especially when such tools seem essentially in direct conflict with system philosophy. I'm just glad there are sane options available still.
drdaeman 12y ago
Well, journald has syslog compatibility layer and can talk syslog, so supporting any existing software is not an issue. It doesn't speak syslog by itself, so it probably can't forward logs to another networked syslog server, but I don't see anything that prevents implementing this, if necessary. The point is, journald also introduces a new protocol that's oriented at logging structured data. This way it not just provides a feature, but forces developers to think about structuring their log output in a machine-readable manner. I think that's the excuse that I believe is the journald's raison d'être and that I personally accept. Just my opinion, though.
- jude- 12y ago
  Compatibility isn't the problem. The problem is the use of structured binary data itself for logs. Logging binary structures instead of raw text makes it very difficult to recover from crashes or misbehavior, since the logging facility (journald or otherwise) must ensure that the log's structure on disk is consistent at all times. I've seen more than my fair share of journald corrupting its own log due to unclean shutdowns. If I'm going to be grepping the journald log file anyway to reconstruct it (possible, but not easy, since journalctl is useless here), then why bother using it at all? It fails at the very task it was built for.
  - bigbugbag 12y ago
    Not sure it was built for the task we expect a log facility to fulfill. I mean the corruption issue is a built in feature of journald: https://bugs.freedesktop.org/show_bug.cgi?id=64116 https://bugs.freedesktop.org/show_bug.cgi?id=64116
  - 12y ago

kiyoto 12y ago

>Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So, forcing a switch through introducing another protocol that has structured data baked-in isn't a too terrible idea. I agree. There is a strong need for common interface(s), and that's a strong part of the motivation behind Fluentd/Kafka/etc. www.fluentd.org/blog/unified-logging-layer

nn3 12y ago

sqlite (or other "real databases") need a fsync for every or at least many transaction to be data safe. Without that it is far more prone to losing data than journald, because with a write ahead log the window for losing data is far bigger. And a journal that has another journal inside it would be somewhat silly. A simple write log can be done better. I don't think fsync on every log commit is a good idea. This would be more a DOS attack. That said I'm somewhat troubled by the cavalier attitude to log data safety in journald too.

e12e 12y ago
I have some difficulty figuring out the use-cases for journald over (some) plainish text log files. Our disks are getting faster and bigger. If you need to consolidate logs you have many options (starting with rsyslogd). If you need to log gigs of data, that can't possibly be kernel/initd logs?! And if it's application logs why not pipe it through something for indexing? By definition if i need kernel/local/init log files it's because something went very wrong: in such cases problems with clean shutdown/startup seems very likely - and in such use - cases plain text to file/serial wins hands down. I'm not against having a wrapper that magically slurps stderr/stdout to timestamped logs -- but if that can't be written cleanly with the apis we have, then surely what we need is to make the minimal improvement in our (probably kernel) api to make writing such a program a trivial exercise? Nothing I've seen of systemd has me convinced the project cares one whit about finding the simplest, least coupled solution to any problem.

ldng 12y ago

Systemd is more like busybox than sysvinit. People bitch about Systemd because they're not foul. Systemd folks (mostly Redhat) have their agenda. I don't mind that. Heck I even agree on some of it. But pushing the whole bloated thing down nearly everyone's throat disguising it as just a simple init replacement is a bit too much.