Hacker News Reader

Comment by Sanddancer | Hacker News Reader

Seeing the removal of syslogd, getting more than a bit grumpy here at the continuing direction Redhat is dragging the Linux world. Journald may serve the basic user well, it can't do half the stuff a good syslogd configuration can do; it can't pipe messages to other processes, it can't send messages to remote servers, it can't send messages to multiple places. If redhat had put in services to let journald do the things syslogd's been able to do since forever, I'd be more ok with its direction, but as it stands, it's proprietary in all but name.

View on HN

It's not a direct replacement. Journald does stuff that syslog can't do, but it doesn't reimplement everything. Instead, you can pipe to syslog if you want syslog features.

- Journald logs the whole boot process

- Journald can make sure that an item really came from some process. It also tries to seal the journal so that it can't be tempered with.

- It's built into the other systemd tools. For example, when you notice a daemon doesn't start through systemctl, it'll show you the error messages in systemctl status.

Note that the second point is quite important -- it provides a rolling hash of the journal contents that you can send to another machine, so that in the event of a break-in, you can detect any tampering with the syslogs. As I recall, this was inspired by the break-in to the kernel.org servers, where the attacker tampered with the log files. That would be impossible with journald.

There are syslog daemons that can provide cryptographic security as well. Alternatively, they can also log directly to an SQL database, use SSL client certificates, etc. Modern syslog daemons are quite powerful.

Yeah, but journald works even on plain stdout, stderr. It's hard to beat that.

It also provides a pretty sensible API for walking through the log from programs.

http://www.freedesktop.org/software/systemd/man/sd-journal.h...

If you need syslogd, isn’t it as simple as yum install syslogd and then you’re sorted?

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.

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?

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.

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.

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.

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

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.

Its only removed from the default install. A lot of fedora users (e.g. desktops) don't really need most of what syslog can do, and those that do can easily install it.

It's an obvious power play by RedHat to force people to use SystemD which is nearly liblinux at this point. As the project subsumes other projects and adds more and more functions that directly rely on SystemD you'll be harder and harder pressed to run a system without it.

One needs to look no further than what their plans for cgroups are to see the future. Not to mention the plans to get rid of /bin/login and VTs.

It's systemd. The way the project is spelled has been explained multiple times. Your criticism is bit weak if you insist on spelling things incorrectly seemingly on purpose. Gives the impression you might also not be completely showing things in an objective light. But oh well.

Anyway, your entire complaint is explained at every systemd presentation. The maintainers want to have something which can be used as the basic building block for Linux. Various other projects now rely on that.

So systemd is successful, but surely it is a conspiracy! hahaha

Fedora is the distro Red Hat uses to test stuff like this. I imagine the full functionality will be available and well understood before a RHEL release incorporates it.

AFAIK it's quite easy to hook up rsyslog to it and then it doesn't make a difference.

That seems a bit inefficient to me, you'd end up with both binary and textual log files.

Presumably if you want syslogd's features, it's for something other than the text log files (logging to SQL, network logging, ...).

If you're doing this, you probably want to disable saving the binary logs -- journald will still retain recent logs from the current boot, so the status commands will still work.

Personally, I uninstalled syslog and enabled binary log retention back when I was running F18, and I'm wishing my Ubuntu and Debian boxes had the same ability.

It isn't what you want, but that certainly doesn't make it proprietary!

Reply on news.ycombinator.com