[systemd-devel] A potentially cross platform solution for process containment in init applications

[Lennart Poettering]

On Fri, 21.03.14 06:53, Rong (tr071 at qq.com) wrote:

> Hi,
> 
> Currently systemd is using cgroups kernel interface for process
> containment. Cgroups is a very easy solution on linux to handle the
> double fork used by daemons, and it can help respawning services in
> case of self-crash. However cgroups seems to be the major stopper for
> systemd to be cross platform.

There's a lot more in systemd that is not cross-platform.

> I'm thinking about an alternative approach for process containment, utilizing the widely accepted FUSE interface in all major unix systems. Below is a brief description:

> a). A fuse daemon will providing a special file system, let's say
> /run/initfs

> b). For every daemon which needs to be contained, we can start a
> helper process first, and open a file in the special file system. For
> instance, to start apache daemon, we start the helper and create/open
> a file "/run/initfs/apache". Make sure close-on-exit is NOT set on
> this file descriptor.

> c). Fork-exec to start the daemon. Now we can identify all process
> with reference to "/run/initfs/apache" as a part of the apache daemon.
> 
> Aside from being cross platform, the FUSE interface also gives very
> powerful api for many advanced functionalities. This initfs file
> server is basically an user space extension of the kernel, just like
> some normal server in the microkernels. You could even have multiple
> instance of such initfs server running on the same box(using separate
> vfs/pid namespace to hide them from each other), thus making init on
> linux containers much easier.
> 
> Any thoughts?

OK, I'll bite.

The good thing about cgroupfs is that processes cannot escape
supervision, unless they are priviliged and do some non-trivial stuff
that cannot happen by accident, very much unlike an fd which anyone can
close and which is closed all the time. Also, cgroups provide us with a
way to list all processes in a unit without priviliges, and to quickly
(without iterating through lots of fds, and without priviliges agin)
determine to which unit a process belongs. Nothing like that works with
your fuse approach.

Also, why involve fuse at all? a couple of fifos in the fs could do
everything else you suggest without relying on fuse...

Also, all big Linux distributions have already switched or have
announced that they'll switch to systemd. That's more than we ever could
ask for, and there's nothing else for us to win.

I can only encourage the other Unixes to come up with their own service
management solutions, that make use of their specific feature set in the
best possible way, so that we get some serious competition in place
again.

Lennart

-- 
Lennart Poettering, Red Hat