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

[Rong]

> 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.
It is very easy in FUSE. You just return an error code when handling unwanted "close()" in the initfs, thus the client can not just close the fd handler unless the process crashes.
It is also easy to maintain a list of processes who opened a particular fd with the FUSE api. No iterating is needed. You can also get the list via lsof/fuser if maintain such lists is too much.

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

Please tell me you are just kidding. The only things you can do with a pipe are read/write/close, that is all. And pipe is even just meant for 1 to 1 communication. unix socket make much more sense, but is not match for what FUSE can do.
With FUSE, you get auto ref-counting by the kernel, you get your hands on all syscalls on filesystem. You can implement your own policy of who has access to initfs, who can close the descriptors, etc.
>
> 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.

Indeed, systemd is taking over most major linux distributions, but this doesn't change the fact that cgroups remains a controversial api, and may go through major api update in the future. I think FUSE approach is cleaner, even without talking about cross platform compatibility.

> 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.

Is there any plan for standardization on configuration file format, so other implementations of init in linux/bsd/whatever could coexist using the same set of conf file for daemons? 

> Lennart
>
> --
> Lennart Poettering, Red Hat
> .