Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Dec 5, 2013 13:11 UTC (Thu) by mezcalero (subscriber, #45103)
Parent article: Another daemon for managing control groups

Jake, "forcing anyone who wants to use cgroups to use systemd clearly isn't"? Really? You think we are "forcing" anything? That's not a very smart thing to say, you know.

How are we forcing anything? People can write as many cgroup controller daemons as they wish. All we do is provide a sane API for cgroups, that you have if you use systemd. That's all. People can use a different init system, and can do whatever they want.

All we do is say that on systemd systems PID 1 is the cgroup manager. And that's because there can only be one, because we need it heavily in PID 1 and since resource management and service management is to 95% the same thing also the lightweightest option.

You know, complaining that PID 1 does cgroup management, and not allowing multiple cgroup managers run side by side is like complaining that you cannot have two libs provide /usr/lib64/libc.so, or that there can only be one PID 1 which gets SIGCHLD for orphan kids, or only one process that gets C-A-Del, and so on...

to post comments

Another daemon for managing control groups

Posted Dec 5, 2013 15:09 UTC (Thu) by jake (editor, #205) [Link] (4 responses)

> Jake, "forcing anyone who wants to use cgroups to use systemd
> clearly isn't"? Really?

Well, Lennart, you provide no alternative and choose to ignore (and not work with) any alternatives. If you can say with a straight face that you do not want *everyone* to use systemd, I would be shocked. And you are doing everything in your power to make that happen. Perhaps that's not force, but it sure is pretty far down that path.

Sorry you didn't like that statement.

jake

Another daemon for managing control groups

Posted Dec 5, 2013 16:24 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (3 responses)

I certainly don't want "everyone" to use systemd. All I am trying to do is cover the major usecases from embedded, to mobile, to desktop, to servers, with a general purpose system manager. If people find our offering compelling, then that's great. If they don't that's fine too by me and I don't care much.

There are lots of cases where you don't need systemd. For example, Google runs on its servers very static images, that know no hotplugging, that have a relatively static cgroup tree and so on. For them, having something that deals with all the dynamic bits like systemd is far less interesting than for the general audience. And that's totally fine.

Why for heaven's sake should I "provide" a second cgroup manager implementation? I only care for systemd. If people don't want systemd, they can use something else, but why for heaven's sake should *I* provide them the cgroup manager for that? My interest is making systemd good, and minimal, and integrated. I am certainly not compromising that in major ways, just to solve problems for people who hate anyway what we are working on? That's pointless, we cannot win that anyway.

If you say we don't work with any alternatives, then a) there acurrently are no alternatives, your story is about code that doesn't exist, about nothing but plans, that haven't even been thought to the end. And b) the work to make this all function in systemd was relatively simple and small, and just makes use of concepts that exist anyway in systemd, like the execution queue, like service management, the dependency tree or device management. We hence got it all done in little time, in in a very nicely integrated uniform way. You can list your cgroups ("scopes" and "slices") next to your services, you can influence them with the same tools, introspect them, and everything. If instead you rip all that out, do it in some separate project, that would be totally new and cross-init system, just to "work with alternatives", then we'd be nowhere, and our code would be much worse and way more complex. So yeah, my priority is quality and simplicity of code and the uniformity and usefulness of the user interface. That's what matters most for me. I will not compromise on that just so that you don't write about us that we "don't work with alternatives".

What you are writing here is not very smart. You are suggesting that I want to make life hard of people who don't want to use systemd. But you are confusing something here: I just *don't care* about non-systemd cases, and I don't have to. I don't care, not because I was evil, just because it's not interesting for my usecase. And I do not actively do anything against alternative impelemtnations of anything (how can I), I am just interested in my own code.

If others don't use systemd and use something else, then that's their choice and *they* have to come up with an alternative implementation, that's certainly not my duty, even if you claim it was.

Over the history of systemd we designed some things which needed little integration with PID 1 in a way that you can split them out and use them outside of systemd. For example, udev, tmpfiles, and hostnamed are components like that. Others OTOH need more integration with the rest of the system and you cannot just isolate them out. Which ones those are are explicitly documented in much detail here: http://www.freedesktop.org/wiki/Software/systemd/Interfac... -- we did that as a service to the people who don't use systemd as PID1. How nice of us! You should appreciate that. It's a question of honesty to list explicitly what is separable and what is not, and so we did that. If something is not separable, then that's due to technical reasons, that's all. And you should grant us that. SO much respect is necessary.

Anyway, Jake, I really don't appreciate what you are writing here. You shouldn't imply that we had ill intentions or when we don't. We don't force anyone to anything. We make an offer, we even make it easy to take only parts of the offer. It's all free. We aren't the only coders around, so if you don't like something, pick something else.

Jake, not cool. Not cool at all.

CGroups manager API

Posted Dec 5, 2013 17:27 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

Lennart,

On a slightly different note, what is your take on trying to have the same API as cgroupsmanager? Did they indeed contact you? Would you be happy to find a common ground?

CGroups manager API

Posted Dec 5, 2013 23:02 UTC (Thu) by drag (guest, #31333) [Link] (1 responses)

> On a slightly different note, what is your take on trying to have the same API as cgroupsmanager

It seems that systemd and cgroupsmanager have distinctly different goals in managing cgroups.

Systemd is looking to provide a high level API that piggy backs on the process management features that already exist and are being used by systemd.

It appears from the posts that I read that cgroupsmanager is looking to expose most of the the functionality of cgroupfs via dbus because the kernel developers are going to depreciate the current cgroupfs API and are discouraging having multiple processes from being able to manage hierarchical cgroups in the future.

It's the difference between trying to make something secure and easy to manage versus something that wants to allow as much flexibility as possible.

CGroups manager API

Posted Dec 6, 2013 1:46 UTC (Fri) by raven667 (guest, #5198) [Link]

I think thats a good summary, the question is whether there is value in systemd also offering the low level interface like cgroupsmanager intends, in addition to the high level interface, or would that break systemd service management if it exposed all the low level details? What kind of clients are expected to be using either of these interfaces, is this for virtualization management agents to setup containers across a shared cluster for customer jobs? Can this use case be accomplished with the kind of interface that systemd is planning to export or does it require the more low level interface that cgroupsmanager intends to export, or can the intended use cases for the dbus interface be accomplished with either system?

It would probably be suboptimal if an application need would create hard dependancies up the stack all the way to the init system such that certain workloads fundamentally can't be run on systems with incompatible init systems. I would prefer to pick the best init system (which I think is systemd) and not lose the ability to run whatever services I want.