Add RFC-5424 syslog forwarding support to `journald` about systemd

[poettering]

Frankly, I am not convinced we should really beef up the forward-to-syslog stuff, because it has the major issue that there's no buffering, i.e. you can never catch up, anything listening will not be able to catch up with what was logged before it started listening.

The various syslog implementations I am aware of nowadays have plugins to read the data they need directly from the journal, and that does provide the buffering so that they can catch up with what was logged while they were offline.

I think rather then beefing this concept up we probably should deprecate it instead, i.e. keep it around and working as it is now, but drop it from the docs, and hide it in the default .conf file we install.

[cipriancraciun]

Indeed, the syslog protocol and implementations has all the issues you've mentioned (and perhaps more).

However, it is also a reasonably simple protocol to implement, and thus there are many small (non-enterprise-ish) tools out there that do implement it (and for which it wouldn't be feasible to implement systemd support).

Thus, having support for it (both in the RFC-3164 and RFC-5424 variants) could offer an easy escape hatch for those that need it, without too much overhead on either side.

---

For example, in my particular use-case, I have written myself a small Go-based syslog server that just stores logged messages in archived (xz / zstd) files. (I know it's not 100% reliable and it might miss messages due to UDP packets drops or in the time it is down, but that is fine.) I use it primarily for HAProxy request logs, but now I have added MQTT support to it for live-watching-filtering of logs when I need them. So, I wanted to also feed in the system log, where I have already configured everything to properly log to journald.

I could for example try to support the journald natively (either via the export format, or reading the log files), however that has two major downsides:

• most implementations for Go rely on the C library that systemd provides; thus linking to them would mean I no longer get easy cross-compilation from Go native build tools; (I now get statically linked binaries;)
• adding support for journald adds lots of complexity (as compared to syslog that I already support); (thus for the moment I'll just patch the code to support the old RFC-3164 format for this socket;)

What I describe here might be viewed as a "me" problem, which I can easily work-around. However this is just an use-case for supporting syslog (and the RFC-5424 format). There might be other similar use-cases out there.

---

I think rather then beefing this concept up we probably should deprecate it instead, i.e. keep it around and working as it is now, but drop it from the docs, and hide it in the default .conf file we install.

I think that would lead to even more perceived lock-in from the systemd ecosystem... (Which I think we already have enough...)