I came across a news entry at Phoronix about a new init replacement, systemd, and curiously started a read into the surprisingly heavy matter. Systemd is by no means as simple as upstart. It does far more things far more straight and in more detail. The differences are so significant that they enforce quite different configuration strategies. One can argue for both, depending on the goal to reach. However, that’s not what I want to write about. After having read what systemd is capable of, and how it does it, I began to put the existence of all system daemons – in their today’s forms – in question.
Though the provided services must be available in userspace somehow, this doesn’t mean that the cores of the belonging system daemons must be implemented redundantly and for the userspace. I don’t even believe anymore that the cores can fulfill their tasks anyhow well in userspace. For explanation: Upstart is a simple event daemon that can start scripts on actively passed events, mainly. In other words, upstart can do classical tasks of an init daemon and serve as a general purpose event handler, but not much more. This is so because upstart was thought as a simple drop-in for the SystemV init daemon, which implied a small code base and as few hacks as possible. Because in userspace there isn’t much more upstart could fulfill in a sane way, it behaves. However, it already comes with quite a few of substitutes for common system tools to be able to behave well in some problematic cases where upstart differs too much from the SystemV init daemon. Upstart can’t just catch the actions of the original tools and decide differently for them.
Systemd observes the full system actively. It observes paths to be informed if a program attempts to access a socket. It observes hardware events to be informed if a resource is available. It even observes mountpoints to dynamically mount resources at access. This is lots of knowledge to gather, maintain, classify and decide about. This also enforces a better understanding and exploitation of the given possibilities on the OS. To some extend, existing services like libudev help out. But, as systemd seems to mimic a system supervisor, it breaks with the classic init-daemon functionality and heads towards a level of control only auditing systems have today on Linux, though for different purpose. The question is if it can do this well, especially if implemented to run completely in userspace?
For comparison, an auditing system sits inside the kernel, to not get compromised from userspace, but mainly to be able to control every action occuring in the kernel that could alter the security of this system. Though this is a very specialized task compared to that of a userspace supervisor, an auditing system observes all the actions a userspace supervisor is interested in. It thus implements similar core functionality. More than that, it is principally capable of doing things a userspace supervisor can’t, like stopping an action from happening or pausing it until something else is done. For example, if systemd recognizes a mountpoint access, it can mount the resource immediately. But, is that quick enough? Systemd has no influence on the accessing process and thus can’t turn it into sleep until the mount happened. Principally, an auditing system could do this. There are other obstacles systemd faces like described in this entry. It goes like inotify is worse because of no atomic access and thus creating racy conditions but found a weird workaround.
Don’t get me wrong. I don’t pledge that the auditing system shall overtake the task of a userspace supervisor. I just conclude that there is redundancy and, because the auditing system is part of the core of the OS, the redundancy occurs with the supervisor. I also conclude that the supervisor can’t really serve its tasks a sane way because it just can’t. This is why I believe that the auditing system has something the other services should profit from.
So why not turning the observing core of the auditing system into an own-standing framework (with scheduling and messaging functionality) and settling the auditing part on top of it as a guest? Why not turning the system daemon(s) into simple feeders and slaves, i.e. guests, and letting them communicate with the new framework via sockets, device nodes, language interfaces or better? A userspace supervisor then would just feed the framework to create observers, actors and callbacks (for commanding a slave to, for example, start a script.) By urgency, the slave might turn into a master and advice the framework to obey immediately before going on (or the framework already knows about such urgencies and only checks for a return message.)
I believe that such a framework could be a very powerful and helpful generic service for both worlds, the kernel space and the user space. It could also turn systemd into THE daemon and make lots of other daemons redundant or shrink to simple slaves (actors). And, only to not be misunderstood, the auditing guest is still configured independently! There is only one observing framework all guests trust on.
What do you think? Could someone prove this concept in reality?
About the author:
Dennis Heuer is just an aged Linux enthusiast maintaining his own Linux home system (from pure source) and being confronted with the above discussed systems and sub-systems on a daily base. Though, he doesn’t understand the inner details of the Linux kernel well and can’t tell how easily his thoughts can be implemented. His viewpoint is that of an administrator.