Hacker News new | ask | show | jobs
by Sanddancer 4574 days ago
I can, however, again, it's a pretty poor direction that only serves to fragment systems. Many of the complaints that drove the creation of journald could have been better solved through a better default syslogd configuration. Additionally, the journald solution for needs such as remote logging or logging to multiple locations means that you now need to pipe through a process that has a near sole job of piping to another process. It just gives a very bad feeling of hackishness to me.
2 comments

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

RedHat Fedora makes no apologies for dropping legacy support. Heck, they threw out ifconfig in Fedora 19.

It's good to be dropping things like syslogd from the default distribution, and the only reason it was ditched was because syslogd is behind the times.

Yes, syslogd does more. If you want those features, install it. Forcing it on everyone, regardless, serves no purpose.

> RedHat Fedora makes no apologies for dropping legacy support. Heck, they threw out ifconfig in Fedora 19.

WTF? Is that because Linux was becoming too easy to use? They have to keep changing it up, so the certification classes have new material to teach. Why wouldn't they keep the command around and wrap whatever re-invented mousetrap replaces it so millions of people can keep typing ifconfig?

It's because change.

Change is how you abandon things that are holding you back. It's how you get rid of the various albatrosses, of which there are many, and clean up the environment for new users.

ifconfig is absolutely not easy to use.

ifconfig was deprecated on linux long ago. While it is compatible with other unixes, it doesn't really map onto the capabilities of the modern linux stack well.

`ip` really is a better tool, and you're doing yourself a disservice if you're not using it, especially if you have anything more than the basic single IP/default gateway network.

> ifconfig was deprecated on linux long ago. While it is compatible with other unixes, it doesn't really map onto the capabilities of the modern linux stack well.

Long ago? Centos 6.4 still has it. My Mac (BSD) has it. I never suggested that it is stupid to add software (ip) that is better, but why would they deliberately remove it when it is such an expected command and works across other unixes? I have trouble believing that it consumes much disk space.

CentOS is not removing deprecated things and Fedora is. This is the difference here.

See: http://en.wikipedia.org/wiki/Ifconfig#Current_status

"Modern Linux distributions are in the process of deprecating ifconfig and route..."

Deliberately removing something means you don't have to maintain it any more and can spend your time improving the better tool rather than bug-fixing the legacy one.

I understand improving, but it wouldn't take much effort to make it user friendly, by wrapping over the ifconfig command for at least the reporting functionality. It could still call ip underneath.

There are ways to handle it that make it backwards compatible and user friendly without only a little extra effort. It's not a sexy task, so who cares about usability.