Linked by Dennis Heuer on Wed 25th Aug 2010 22:23 UTC
Linux 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.
Permalink for comment 438390
To read all comments associated with this story, please click here.
Member since:

"it even spreads into user-space libraries and tools.

That is just to configure it. There is really no way to do that without user space tools.
there are auditing systems that don't taint coreutils, for example ;)

I highly doubt Linux would ever let an auditing system launch arbitrary daemons. And that's because it wouldn't make any sense.
There is absolutely no duplicated functionality. None of the things that SystemD does with the kernel are done by the auditing system, and vice versa. The only possible thing I can think of would be that an auditing system could do the job of AutoFS. But that would be a really bad idea. AutoFS is much better for that purpose.
The "generic observing system" is the auditing system. There is really little reason for observation of processes other than for security or debugging.

you seem to get my article wrong. possibly the term to observe creates this strong relation to the auditing system that you think they are the same. but, please, go on birds perspective and overlook the kernel scape. you will see that, even if systemd is not observing by itself, at some point in the chain there is an observer because otherwise there would be no action on events. you would rather call this event handling or the like, but to observe is fully correctly used here in terms of the english language. think of a star observer. yes, in many cases the observation can be settled very deep into the kernel internals. but that is of different matter. anyhow there must be observation for events, and there is always a reason why.

this reason may be defined far outside the kernel in a user script. but the job ticket must get through down to the observing unit, being mangled and translated some times on the way. so it is, and both the auditing system and systemd somehow need to create such tickets for an observer or even to create an observer itself, depending on the kernel interfaces they hook in.

beside that - and here we come to what my article is about - both create a system to parse rules, to create types (struct's) of contexts, to pass these contexts as tickets, etc. think in terms of structures. many programs re-invent structures for the very same purpose: scanning rules to create internal contexts to type and register them at the correct interfaces and bind them to chains, an event handler, or whatever.

this generic way of doing things i mean. this is what the framework could encapsulate and offer a way that both the auditing system and systemd, but also udevd and other services, can profit from it. i could write my own rules in guile and register them via an ffi, circumventing systemd. but systemd would be notified about the change and could update its state or possibly act against my script - possibly via the auditor.

possibly you now see that what i target at is a more generic, say, job center for kernel observation or instruction that provides principles for simple job-creation and allows for even more flexibility because of being accessible arbitrarily and even in concurrency, managing the states for the listeners and feeders.

Reply Parent Score: 1