On Mon, Jun 24, 2013 at 6:27 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Sat, 22.06.13 15:19, Andy Lutomirski (l...@amacapital.net) wrote:
>> >> 2. I manage services and tasks outside systemd (for one thing, I >> currently use Ubuntu, but even if I were on Fedora, I have a bunch >> of fine-grained things that figure out how they're supposed to >> allocate resources, and porting them to systemd just to keep working >> in the new world order would be a PITA [1]). >> [...] > >> I think that what I want are something like sub-unit cgroups -- I >> want to be able to ask systemd to further subdivide the group for my >> unit, login session, or whatever. Would this be reasonable? >> (Another way of thinking of this is that a unit would have a whole >> cgroup hierarchy instead of just one cgroup.) > > The idea is not even to allow this. Basically, if you want to partitions > your daemon into different cgroups you need to do that through systemd's > abstractions: slices and services. To make this more palatable we'll > introduce "throw-away" units though, so that you can dynamically run > something as a workload and don't need to be concerned about naming > this, or cleaning it up. > Hmm. My particular software can maybe live with this with unpleasant modifications, but this will break anything that, say, accepts a connection from a client, forks into a (possibly new) cgroup based on the identity of that client, and then does something. How can this support containers or the use of cgroups in a non-systemwide systemd instance? Containers may no longer be allowed to escape from the cgroup they start in, but there should (IMO) still be a way for things to subdivide their cgroup-controlled resources. If I want to have a hierarchy more than two levels deep, I suspect I'm SOL under this model. If I'm understanding correctly, there will be slices, then units, and that's it. > >> 4. As mentioned, I'm on Ubuntu some of the time. I'd like to keep >> the same code working on systemd and non-systemd systems. >> >> How hard would it be to run systemd as just a cgroup controller? >> That is, have systemd create its slices, run exactly one unit that >> represents the whole system, and let other things use the cgroup >> API. > > I have no idea, I don't develop Ubuntu. They will have to come up with > some cgroup maintenance daemon of their own. As I know them they'll > either do a "port" of the systemd counter part (but that's going to be > tough!), or they'll stick something half-baked into Upstart... > > Sorry, if this all sounds a bit disappointing. But yeah, this all is not > a trivial change... > I'm worried that the impedance mismatch between systemd and any other possible API is going to be enormous. On systemd, I'll have to: - Create a throwaway unit - Figure out how to wire up stdout and stderr correctly (I use them for communication between processes) - Translate the current directory, the environment, etc. into systemd configuration - Translate my desired resource controls into systemd's "let's pretend that there aren't really cgroups underlying it" configuration - Start the throwaway unit - Figure out how to get notified when it finishes Without systemd, I'll have to: - fork() - Ask whatever is managing cgroups to switch me to a different cgroup - exec() This is going to suck, I think. --Andy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel