Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Binary logging would be fine if it Just Worked, but my experience is that journald/journalctl does not just work, and when it breaks I don't have logs.
For example, if the system clock is not monotonic, my text logs are still written sequentially in order, and it's easy to figure out what happens. It is the stated view of the journald maintainers that, if your clock is not monotonic, you get to keep both pieces. https://github.com/systemd/systemd/issues/662 (The specific issue described there sounds complicated, but the fundamental problem behind it, which I have hit multiple times, is "if your system can't maintain a monotonic clock at all times, including early boot, then your logs will be mangled.")
Similarly, a text log line is complete the moment it's written, even if the process that wrote it goes away immediately afterwards. Journald, by contrast, performs asynchronous metadata lookups for _each_ log line at some later time, which it apparently does not cache. This means that, when a process dies suddenly, the final messages will not appear in "journalctl -u", because they failed to get tagged with metadata. (I can't find the bug for this, so I haven't verified that it's still open and unfixed at this time. But it has certainly existed for years at this point.)
So no, in principle I have no objection to _competent_ binary logs. Journald does not meet that bar.
That's nice and it showcases how Nix can create a declarative process management atop a script-based imperative manager. How is your experience with it? Also note that there's https://github.com/svanderburg/nix-processmgmt, a manager agnostic processes management framework supporting s6 among others, but your way seems a bit more straightforward.
- Because S6 uses the service-directory to store state-files in the same directory (no /etc-/var split).
1: https://github.com/NixOS/nixpkgs/pull/122844
It's not really a binding. It doesn't link to anything in systemd, it's just aware of the convention used by systemd to pass the file descriptors into the process. The actual code being executed from that repository is around 60 lines, I guess:
https://github.com/coreos/go-systemd/blob/main/activation/li...
I just used that rather than writing it myself because it felt like it didn't add much to the story.