Hacker News new | ask | show | jobs
by CraigJPerry 4574 days ago
I don't think the fragmentation claim stands up to scrutiny.

It's so far been adopted by redhat, suse, arch, coreos and with some consideration by debian. The only big name not thinking about it is Ubuntu.

I don't think that many of the journald drivers could have been solved by better syslogd configuration, for example journald cryptographically signs each log entry. Even if you get root on my box, you can't edit an entry without me knowing. That's not possible in any meaningful way with syslog.

I don't share the view of a hack, the speed improvements of introducing journald have been tremendous and usability is mostly better.

For example, the number 1 thing done with syslog output is probably either grep it, so journald improves on this:

    journalctl _COMM=sshd --since yesterday --until "08:30"
    OR
    journalctl /usr/sbin/sshd --since yesterday --until "08:30"
Or tail it

    journalctl -F
The places i don't like the user interface are around starting and stopping services. However the old interfaces work fine for now.
2 comments

Think bigger than Linux. Think those with freebsd boxes, netbsd boxes, solaris boxes, etc. They're all very much relevant, but left out in the cold by deliberate decisions of the systemd folks to eschew compatibility. Functionality-wise, journald has no way of acting on the messages it receives. With syslogd, it's fairly trivial to write a script that will send a nagios alert every time a service is restarted, for example. How does one do that with journald?
The init system differed a lot across distributions. Systemd made it more the same within distributions. Solaris uses something systemd like. *BSD use their own thing.

I don't get what you're complaining about, the fragmentation has been reduced :P

systemd itself provides the functionality to run commands at points during the lifecycle of a service[1]. As for the people in mixed environments, you can forward journald to syslog [2].

[1] http://www.freedesktop.org/software/systemd/man/systemd.serv... [2] http://www.freedesktop.org/software/systemd/man/journald.con...

That's a tiny sliver of what you can do with syslog piping. For example, fail2ban works by piping the contents of the auth stream of syslog -- usually also put into auth.log -- into a script that monitors for bruteforce attempts. This kind of reactivity is a lot harder on journald configurations.
There have been various tools which have done this. And a lot had huge security bugs. Despite what you claim, this is also easily doable with journal plus similar solutions are available for journal.
ehm. no. it can just stream the output of `journalctl -f`.

it can filter even better than before, because fail2ban usually does not care about everything in `auth.log`. i guess i don't see the problem.

Sensible command line UIs? You've made a believer out of me.

How does this affect something like a remote syslog? Could I send the syslog output of my router to journalctl?