Incompatible with fern 0.5.x

[mmstick]

It seems that the FernLog type was removed in 0.5.1 in 2017-12-26

[mmstick]

Seems log::Log and syslog::Logger are the replacements.

[daboross]

Yep- though I didn't actually realize this crate uses the systemd crate rather than syslog. If systemd has additional capabilities that sylsog doesn't, fern could definitely add support for it.

There's documentation for using syslog directly in fern at https://docs.rs/fern/0.5/fern/syslog/index.html.

[blackghost1987]

This crate was a quick and dirty solution for logging directly in the systemd journal, it's not really well polished or regularly maintained. I can try to make this work with Fern 0.5 though when I'll have some free time.

But if @daboross thinks Fern should have an official systemd support, then that would be a much better and cleaner solution and it would render this crate obsolete.
I'm not really sure what are the additional capabilities in the journal related parts of the systemd crate, but I can imagine there are some, as systemd is newer and more complex than syslog.

[daboross]

I'm not really sure what are the additional capabilities in the journal related parts of the systemd crate, but I can imagine there are some, as systemd is newer and more complex than syslog.

This was pretty much my point of view on things too. I've looked a bit more but all I can tell is that systemd::journal and syslog have seemly completely different bits of information one can pass onto journald. systemd allows sending level as a usize (???), file, line and module_path, none of which syslog allows. But syslog translates a log::Level to something, and includes pid, process string, hostname, and a "facility" enum.

I'm also not 100% sure whether syslog is sending to a completely different non-systemd-specific interface. Or if systemd::journal isn't systemd-specific either?

---

I'd probably want to do more research before implementing a hook for systemd::journal directly into fern, or at least have someone who knows more about the subject make an educated comment on the matter.

[PAStheLoD]

Hello!

In theory journal fields should cover every syslog field, of course maybe with different names.

syslog is defined in an RFC somewhere (RFC 5424 since 2009, before that there was 3164 since 2001), and all of it is a bit useless, because none of it is kernel enforced. (So any program can log as any facility, at least to my knowledge.) Whereas journal tries to get these bits of information (process binary path, etc) from the kernel directly (PID is attached to messages for example if using a unix domain socket), and from procfs (which can of course lead to a bit of a performance bottleneck, that got addressed by throwing a cache there in v235).

So the "journal protocol" can be thought of as stable.

It'd be great if Rust could log to systemd without the need for libsystemd during compilation (would help with cross compiling, etc), but otherwise there's no point in re-implementing the handling of all the special fields that are part of journald's structured log messages (that is the real feature, not the syslog compatibility).

Sorry for the haphazard comment, it's a bit of a chicken and egg problem, as it depends on what currently the systemd crate can do, what fern targets (does it want to support arbitrary key-value metadata for logging? journald supports that, syslog only supports unstructured byte arrays (text basically)). And usually when people want systemd logging (jorunald) integration they either don't know what they want and syslog is (or would be) fine for them, or they want to explicitly use some kind of journald only thing.