Hacker News new | past | comments | ask | show | jobs | submit login

I think journald is by far the buggiest component systemd has. Log corruptions, the dubious Forward Secure Sealing mechanism, journal file fragmentation, the gateway daemon, coredump hooks. There's been several CVEs for it, too. Of course, you cannot disable it without source code modification.

Quoting from the systemd wiki [1]:

   Note that it is now the journal that listens on /dev/log,
   no longer the BSD syslog daemon directly. If your logging
   daemon wants to get access to all logging data then it
   should listen on /run/systemd/journal/log instead via
   the syslog.socket unit file that is shipped along with
   systemd. On a systemd system it is no longer OK to listen
   on /dev/log directly, and your daemon may not bind to the
   /run/systemd/journal/syslog socket on its own. If you do
   that then you will lose logging from STDOUT/STDERR of
   services (as well as other stuff).

   ...unless your syslog implementation is socket
   activatable many services will not be able to log to your
   syslog implementation and early boot messages are lost
   entirely to your syslog implementation.
So the fact that keeping your regular syslogd wasn't as simple as merely symlinking syslog.service was publicly known, but often overlooked by proponents during discussions.

[1] https://wiki.freedesktop.org/www/Software/systemd/syslog/




That's just bad, this is breaking API's ... suddenly other logging deamons need to change their code because systemd is squatting the log file ?!?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: