[Sanddancer]

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?

[bkor]

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

[dignan]

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...

[Sanddancer]

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.

[bkor]

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.

[ibotty]

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.