supervisordgot the service management done, but I never got the logs stored anywhere sensible. Eventually, I got tired of being tapped to debug anything that had an obvious error, but where the message was only logged by supervisord.
Thus began a quest for running things through the distribution’s init system, which has given me some experience with
upstartand a lot of experience with
systemd. Like most software that reaches success, systemd has not been carefully designed and implemented. It has only accumulated, organically.
This is nowhere more obvious than in the configuration system. I can’t just read documentation online, write a
.servicefile, and expect it to work; I have to use the online search to find which man page they hid the relevant directives in, and spin up a VM to read it. Once I find the directives that apply, it’s obvious that we have an INI system crying out to be a more imperative, stateful, and/or macro-driven language.
Those are related; because the configuration is underpowered, new capabilities require new tweaks. Consider the number of “boolean, or special string value” options like
ProtectSystem: these were clearly designed as booleans and then extended later.
Because the website doesn’t keep a changelog—everything changes so fast,
systemdjust has a major version and every release is breaking—it’s not easy to build a cross-platform service definition file that takes advantage of the features
systemdoffers. You know, the things that make it unique from other init systems. The things that were supposed to be selling points.
It’s because everything changes at the whim of the developers. Stable? Backwards-compatible, at least? In a fundamental system component?
Big nope from the
systemdteam. There are at least a few directives that were superseded, and so it’s impossible to make a portable service description for a service that is otherwise portable. And the lack of past-proofing tells us about future-proofing. What you write today may simply not run tomorrow.
systemdwas supposed to be the obvious, easy choice: in theory, it embraced Linux and cgroups so that administrators could use cgroups to provide isolation without a separate containerization layer. But in practice, the separate layer is looking ever more like a better choice.
Post a Comment