6 ms·

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

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.

mateuszf 13y ago
AFAIK it's quite easy to hook up rsyslog to it and then it doesn't make a difference.
- brokenparser 13y ago
  That seems a bit inefficient to me, you'd end up with both binary and textual log files.
  - anonymouscowar1 13y ago
    Presumably if you want syslogd's features, it's for something other than the text log files (logging to SQL, network logging, ...).
  - andrewaylett 13y ago
    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.
DrJokepu 13y ago
If you need syslogd, isn’t it as simple as yum install syslogd and then you’re sorted?
- Sanddancer 13y 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.
  - CraigJPerry 13y 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.
    - Sanddancer 13y ago
      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?
      - 13y ago
alexlarsson 13y ago
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.
rbanffy 13y ago
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.
andor 13y ago
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.
- hdevalence 13y ago
  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.
  - Sanddancer 13y ago
    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.
    - mateuszf 13y ago
      Yeah, but journald works even on plain stdout, stderr. It's hard to beat that.
- rwmj 13y ago
  It also provides a pretty sensible API for walking through the log from programs. http://www.freedesktop.org/software/systemd/man/sd-journal.html http://www.freedesktop.org/software/systemd/man/sd-journal.h...
pekk 13y ago
It isn't what you want, but that certainly doesn't make it proprietary!
airencracken 13y ago
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.
- bkor 13y ago
  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

mateuszf 13y ago

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

brokenparser 13y ago
That seems a bit inefficient to me, you'd end up with both binary and textual log files.
- anonymouscowar1 13y ago
  Presumably if you want syslogd's features, it's for something other than the text log files (logging to SQL, network logging, ...).
- andrewaylett 13y ago
  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.

DrJokepu 13y ago

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

Sanddancer 13y 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.
- CraigJPerry 13y 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.
  - Sanddancer 13y ago
    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?
    - 13y ago

alexlarsson 13y ago

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.

rbanffy 13y ago

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.

andor 13y ago

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.

hdevalence 13y ago
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.
- Sanddancer 13y ago
  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.
  - mateuszf 13y ago
    Yeah, but journald works even on plain stdout, stderr. It's hard to beat that.
rwmj 13y ago
It also provides a pretty sensible API for walking through the log from programs. http://www.freedesktop.org/software/systemd/man/sd-journal.html http://www.freedesktop.org/software/systemd/man/sd-journal.h...

pekk 13y ago

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

airencracken 13y ago

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.

bkor 13y ago
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