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.
Thread beginning with comment 438238
To read all comments associated with this story, please click here.
Systemd doesn't quite work like that
by Zifre on Thu 26th Aug 2010 00:27 UTC
Zifre
Member since:
2009-10-04

Many of the arguments in the article are based on an incorrect understanding of how SystemD works. Ultimately, an auditing system would not be capable of most of the things that SystemD does (unless it were made into a rampant layering violation ;) ).

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 not completely true. SystemD doesn't have to actively observe and act upon any of the things that you mentioned. Sockets are created ahead of time, and SystemD leaves them alone (the kernel buffers the data). Hardware events are mainly observed by Udev (SystemD has very little hardware logic). And mount points are handled by AutoFS, also in the kernel.

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.

Actually, SystemD can and does do this. It sets up AutoFS mounts. Any access will cause the process to block until the real file system is mounted. An auditing system would not be able to do this any better than SystemD can.

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.

An auditing system would not be able to fix this problem. What is needed is a transactional file system. I am actually working on a transactional file system layer for the Linux kernel (about which I may write an article for OSNews someday ;) ).

Edited 2010-08-26 00:27 UTC

Reply Score: 5

ciplogic Member since:
2006-12-22

Fully agree. SystemD is about integration and much basic monitoring. The fact that a subsystem is restarted automatically if it crash. does not make that all systems (daemons, services, whatever) are obsolete and the rest is "the service". A daemon that restarts automatically the X Server, in case of crashing or if user is in graphic mode, does not make it that the X Server is obsolete.
So I the author simply gets the fact that SystemD will do a better logic to restart services and so on, but the final conclusion is wrong.

Reply Parent Score: 2

the_author Member since:
2010-08-26

Ultimately, an auditing system would not be capable of most of the things that SystemD does (unless it were made into a rampant layering violation ;) )

i believe that SELinux is such a rampart layering violation. it even spreads into user-space libraries and tools. but the real fact SELinux proves is that auditing sytems are meant to become omnipotent. so, can you safely state that an auditing system will _not_ implement everything systemd is dreaming of into its observing code?
SystemD doesn't have to actively observe and act upon any of the things that you mentioned. Sockets are created ahead of time, and SystemD leaves them alone (the kernel buffers the data). Hardware events are mainly observed by Udev (SystemD has very little hardware logic). And mount points are handled by AutoFS, also in the kernel.

this rather sounds like you agree to the simple truth that things are better done inside the kernel, and supervisors should only feed and serve. i conclude from this that systemd is quite working on the same layer/interface for just everything inside the kernel as the auditing system, and there _is_, as a result, doubled core functionality.
Actually, SystemD can and does do this. It sets up AutoFS mounts. Any access will cause the process to block until the real file system is mounted. An auditing system would not be able to do this any better than SystemD can.

again, my article targets at the cores of the implementations, the observing parts. if the auditing system can do this in the kernel, why we need it another time outside the kernel? in other words, if an auditing system can't do it _better_ than systemd, does that justify a layer in userspace? where should the generic observing interface reside, and how should userspace daemons settle on it? that is my question.
I am actually working on a transactional file system layer for the Linux kernel (about which I may write an article for OSNews someday ;) ).

this is interesting. could you please tell how it shall act (inside the kernel) and why an auditing system is not interested in it?

Reply Parent Score: 1

Zifre Member since:
2009-10-04

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. But yeah, I don't like SELinux very much... it's way too complicated.

so, can you safely state that an auditing system will _not_ implement everything systemd is dreaming of into its observing code?

Yes, actually. I highly doubt Linux would ever let an auditing system launch arbitrary daemons. And that's because it wouldn't make any sense. The old uevent helper system proved that it's always better to let user space launch things.

i conclude from this that systemd is quite working on the same layer/interface for just everything inside the kernel as the auditing system, and there _is_, as a result, doubled core functionality.

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.

why we need it another time outside the kernel?

It's not outside the kernel. AutoFS is part of the Linux kernel. The reason that SystemD has to setup the AutoFS mounts rather than the kernel is because the kernel has no business reading configuration files. Policy decisions belong in user space.

where should the generic observing interface reside, and how should userspace daemons settle on it? that is my question.

The "generic observing system" is the auditing system. There is really little reason for observation of processes other than for security or debugging.

this is interesting. could you please tell how it shall act (inside the kernel) and why an auditing system is not interested in it?

A transactional file system would allow programs to have a consistent snapshot of the file system. An entire transaction (which could last an indefinite amount of time) is an atomic operation. For example, a package manager could install software in a transaction. Then, if the power goes out, you will not be left with an inconsistent state. The downside is that performance is slightly decreased, and there can be conflicts (e.g. A writes to a file that B is trying to read). Unlike many transaction systems, there is no blocking. Basically, if A reads something in a transaction, and B writes to that thing in a transaction, the transaction with the lower priority is terminated. Individual, normal file operations are treated as transactions with infinite priority, so normal programs never have to worry about the transaction system. If an auditing system were to maintain all this logic, it would be a huge layering violation.

Reply Parent Score: 2