Hacker News Reader

Comment by buster | Hacker News Reader

I didn't know that systemd also provides a syslog functionality. But it makes me wonder:

- the wiki pages mention that the default syslog should be removed because it makes no sense to have two solutions

- the pages also say that for more features you should install a "real" syslog solution (rsyslog, syslog-ng)

Question: Why does systemd then come with syslog functionality in the first place?!

This is a honest question, not trolling, what will i gain from systemd journal? Everything points to a) pain to switch and b) less functionality. Whatever that is..

After reading a bit, it appears that this journal is some binary data.. Call me old fashioned but i really like my easily transferable and everywhere readable plain text logs.. why is it binary?!

* https://fedoraproject.org/wiki/Changes/NoDefaultSyslog

* https://fedoraproject.org/wiki/Features/systemd-journal

Edit: Thanks for the explanations on the binary format, much appreciated.

View on HN

The journal has been introduced as the natural way to manage logs now that systemd takes care of all the output of daemons.

> If you are wondering what the journal is, here's an explanation in a few words to get you up to speed: the journal is a component of systemd, that captures Syslog messages, Kernel log messages, initial RAM disk and early boot messages as well as messages written to STDOUT/STDERR of all services, indexes them and makes this available to the user.

While syslogd and Co. just take care of moving the debug statements from RAM to the disk or to a network device, the journal is meant from the beginning as an interface for querying the logs, for example

    $ journalctl -u httpd --since=00:00 --until=9:30

[1] http://0pointer.de/blog/projects/journalctl.html

Call me old fashioned... but what's wrong with grep? If you need more features like searchable metadata, the other logging solutions are already pretty full-featured.

I know this goes back to the old holy war of modular versus... not modular(?), but personally I prefer the modular approach.

The other answers give some of the advantages of journal, but imho fail to capture the philosophical underpinnings; or the real reason it's there.

Traditionally, unix systems have had a very distinct and different processes for managing the system during bootup and runtime. For hardware, there initially were only the bootup systems and hotplug was added haphazardly a piece at a time, and it never really worked properly in all corner cases. Non non-systemd systems, it still doesn't.

A lot of the justification of systemd is to unify the bootup and runtime systems, so that there is only one, and there should be no difference to a daemon or a driver if it's pulled up during bootup or when it's plugged in or by the user from console. This unification makes the system simpler, saner, and much more robust. However, it means that there has to be large-scale changes in system architecture. One of those changes was that logging interfaces need to be available before init forks the first time, and among other things, before filesystems. This meant that old logging daemons just couldn't do the job.

I could believe that some people buy into this explanation. However I get the impression the real reason those older systems bother Poettering is that they weren't written by him.

I would say that Poettering could have gotten all of this go a lot smoother had he just contacted the rsyslogd devs and worked out something with them before embarking on writing a new logging daemon. Not doing so probably cost him 6 months of adoption, and was probably caused by a personality flaw.

However, the technical reasons why a new one was needed are very valid.

According to the design document [0] the primary reason is this problem with syslog: "Binary data cannot be logged, which in some cases is essential (Examples: ATA SMART blobs or SCSI sense data, firmware dumps)"

Also, instead of lines of utf8 strings, the systemd format is extensible. This means applications can store additional meta data without some syslog-grepping script breaking.

[0] https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...

I can totally relate to wanting to extend log output without (too much) fear of breaking consumers with every change. I was excited to read http://tools.ietf.org/html/rfc5424 where section 6.3 describes structured data storage in syslog. However, I have yet to see anyone using this in production, and I haven't had the opportunity to try it myself.

I didn't know that either. From reading the linked thread in OP, it seems like the idea is that the systemd journal comes in at a lower level (started from initrd? kernel module? no idea...), so it helps with debugging early boot process before /var is mounted. But I also think there should be standard syslog for reasons I just mentioned in another comment. Seems like there are good reasons to have both.

It's syslog-compatible: http://www.freedesktop.org/software/systemd/man/systemd-jour...

I'm not sure why they don't also write a text log. I guess it would mean giving up their nifty cryptographically-verified-authentic binary format.

I may be wrong, I haven't booted up my fedora machine in a couple months.

They wouldn't have to give that up by writing a text log. They'd just be presenting more than one source of truth about the the log, from less secure to more secure.

The new (binary) format is better structured and it also has a bit of extra security (signatures).

Reply on news.ycombinator.com