|
|
Log in / Subscribe / Register

Another daemon for managing control groups

Another daemon for managing control groups

Posted Dec 5, 2013 6:55 UTC (Thu) by zdzichu (subscriber, #17118)
In reply to: Another daemon for managing control groups by Baylink
Parent article: Another daemon for managing control groups

systemd is becoming *the* Linux userspace.
Just like glibc is *the* Linux system libc. There are other contenders, but they occupy their small niches.


to post comments

Another daemon for managing control groups

Posted Dec 5, 2013 11:03 UTC (Thu) by rwmj (subscriber, #5474) [Link] (6 responses)

It's not the same thing. glibc provides a broad API, but with definite limits, and you can easily replace bits of glibc. Need to use a GUI? Link with gtk. Need a different way of handling memory? Link with talloc. You can even replace (for example) all str* functions with stricter versions from an external library.

systemd is a fine way to manage daemons, but there's no reason why it couldn't use a library or separate process for cgroup management.

Breaking up monolithic daemons into separate processes and libraries with well-defined interfaces between them is both the Unix philosophy AND a better way to develop more reliable software.

Another daemon for managing control groups

Posted Dec 5, 2013 11:17 UTC (Thu) by hummassa (guest, #307) [Link]

Actually, the only pro-systemd argument I heard that makes a lot of sense seems to contradict you and goes in the "yo dawg, I'll make init, that is a daemon, to init and manage the deamon that will init and manage the other daemons so you can init and manage the deamons" direction. If systemd/sysv-init will manage one deamon-managing process, isn't it the same as managing all the deamons? I really don't have an answer.

Another daemon for managing control groups

Posted Dec 5, 2013 13:03 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (4 responses)

Same thing with systemd. You don't like logind? Turn it off at compilation, use ConsoleKit instead. Don't like journald? Just run syslog, too. Don't like it's SELinux support, then turn it off. Don't like its bootchart implementation, then turn it off, maybe use another one. Don't like its readahead implementation? Then turn it off, use another one. There are 35 things you can turn/off with configure switches, to tailor it exactly to your needs. And distros can split up systemd into multiple RPMs/DEBs if they desire so and make use of them independently.

However, there are a few things you cannot turn off: That's PID1's process management of which cgroups is part of. That's udev device management and that's the journal (but you can turn off the journal's storage on disk, we however need it to pass stdout/stderr of all daemons through).

And yes, there are tons of reasons why you want cgroup management in PID1: because it's trivially easy there and simple, and it is not if you do it outside of PID1. If you do it out-of-process, you need to replicate pretty much the entire state of your service manager in your cgroup manager, since the entities that are resource managed are in 95% of the cases exactly the same entitites that are service managed. So splitting them up means you need some form of IPC that constantly replicates the entire tree of services from PID1 in that other cgroup daemon. That's fragile and messy, and a lot of unnecessary code. IPC always is. Then, there is the issue of cyclic deps: a good PID 1 knows at any time securely and reliably of each process to which service it belongs. That's easy to do with cgroups. However, if cgroup management is done outside of PID1 in a different process, then PID 1 suddenly becomes a client to that other process, while that other process is also a managed process PID 1 wants to use cgroups to manage for. To start and manage that other daemon that will allow you to deal with cgroups you need cgroups in the first place. And that's just broken.

Beyond that: When doing cgroups you need an execution queue of some kind and you need a dependency tree between your groups, so that you can always rebuild your tree from the root down, in the right order, with each property set before you go to the next child. You also need to dynamically react to devices coming and going and rebuild/refresh your tree since many cgroup props take device major/minor pairs which are pretty much dynamically assigned to devices these days. You also need to be able to deal with groups coming, and going, and possible propagating changes then to other groups on the same level. Soooo, an execution queue that is based on a dependency tree that is influenced by services/cgroups coming and going and devices coming and going, that's pretty much exactly what systemd *is*. If you avoid doing this in PID 1 then you are just recreating systemd a second time in a different process. A lot more code to write, to test, to spend resources on. I am sorry, but I am just not going to write or help building such a needlessly complex system. You can have it easy and small and today. I am really not interested in having it complicated, redundant, larger and one later day.

(And no, a library certainly doesn't work at all for this, you need to cross the privilege boundary and a single active queue dispatcher, which doesn't really make a library such a good choice...)

Another daemon for managing control groups

Posted Dec 5, 2013 19:03 UTC (Thu) by butcher (guest, #856) [Link] (3 responses)

I believe it's good to have both, systemd/cgroups and cgroupd, but I'll probably be buildroot-ing images with systemd/cgroups. It seems like a more appropriate factoring of functionality.

Thanks all involved for the ability to choose.

Another daemon for managing control groups

Posted Dec 5, 2013 20:18 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

> I believe it's good to have both, systemd/cgroups and cgroupd,

Why is it good to have both?

In what way is systemd's solution inadequate?

Another daemon for managing control groups

Posted Dec 5, 2013 20:55 UTC (Thu) by jake (editor, #205) [Link] (1 responses)

> In what way is systemd's solution inadequate?

I think primarily the problem that some people have with systemd's solution is that it requires running systemd as the system's init, which some do not want to do. According to Lennart in http://lwn.net/Articles/575847/ there are "lots of cases where you don't need systemd", but if you want to use cgroups you (will) need some kind of manager.

systemd's solution may well be perfectly adequate (or, in my mind, way better than 'adequate'), but it does require systemd.

jake

Another daemon for managing control groups

Posted Dec 6, 2013 18:06 UTC (Fri) by drag (guest, #31333) [Link]

> but if you want to use cgroups you (will) need some kind of manager.

Yes, but only one can be used at a time. So any solution that will provide cgroups management will have the same problem as systemd.

No really good way to fix this I expect.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds