> https://github.com/arsv/minibase/blob/master/src/misc/runcg.c > > It's really simple. > > I don't think a tool like this has any actual uses, other than in > arguments with systemd fans, but I guess that alone could justify > its existance.
Thanks for this link this is really interesting. Well, for me, cgroups is clearly a lack to s6. Using it for every process like systemd do have no sense, but in some case it can be useful to protect e.g an "over-eat" allocation memory by a program (in particular over a server). As cgroups is a linux specific feature, s6-supervise should not take care about it even if the code is modified at compile time. This will increase the code of s6-supervise only for an "optional" features. But laurent you do what you need to do. I would prefer an extra layer of supervision and independent from s6 uniquely used when it necessary. I think about it from a while for 66. Adding a section like [cgroups] containing all @key field needed to configure the future cgroups environment is not a big deal and allow user to quickly define what it need. In such case the "extra supervision layer" is added to the run scripts which execs the e.g runcg program. But maybe i'm totally wrong with my thought... -- eric vidal <e...@obarun.org>
