On Wed, Sep 14, 2011 at 01:05:21PM +0200, Jan Safranek wrote: > Hi, > > the thread got a bit stalled and full of ideas, without any real code. > So, if I understand it correctly, libcgroup needs to implement this: > > 1. cgconfig service (optionally) creates groups with sticky u+t bit on > tasks files. It's currently possible with 'fperm' option
What is fperm option? I atleast do not find any description in man page of cgconfig.conf. > in > cgconfig.conf, but that needs to be specified explicitly for each group, > so I think of new '-s' option to cgconfigparser to set the sticky bit > globally for whole cgconfig.conf for lazy admins. I think we can make it default and if need be provide a config option --no-sticky-bit etc to change that default behavior. In fact to begin with I will say do not provide any option to override this behavior till somebody really asks for it. > > 2. cgconfig service (optionally) should not mount controllers. This is > IMHO already implemented, 'mount' section is optional in today's git. That's good. Distributions can come up with their own default files and the ones adopting systemd, can make it empty by default. I think that's how it is in fedora. > > 3. cgconfig service restart and stop should be 'nice' to systemd and > other cgroup apps (libvirt, ...). I understand the previous discussion > that 'cgconfig stop' should just remove only the groups that were > created by 'cgconfig start' and only if they are empty. Please correct > me if I am wrong. I think this makes sense. Cgconfig provides infrastructure for persistent groups and I think should not try to claim dynamically created groups once service is being stopped. It creates problems especially with shared groups where groups are being shared with systemd. > > If this is the case, 'cgconfig start' should track the cgroups it > created, so 'cgconfig stop' knows, what to remove. This means both > cgconfigparser and cgclear needs to be changed to write/read the > tracklog to/from /var or /run (TBD). 'cgconfig restart' would naturally > delete only empty groups (like 'stop') Doesn't "service cgconfig stop" delete everything. Any group which are being used, are first emptied (tasks are moved to root group) and then cgroups are deleted? Talked to lennart and he agreed with the idea that lets not move processes out of cgroup if it is being used. > and create new groups according > to (potentially new) cgconfig.conf (like 'start'). The 'restart' would > of course set permissions and group parameters of *all* groups defined > in this cgconfig.conf, even those which were already created before > (again, like 'start'). Setting permissions according to cgconfig file even for already existing group should be fine. Again, lennart seemed to agree to it saying it should not impact systemd even for shared group. If we decide to mark cgconfig created groups as sticky, then we probably don't have to maintain any additional state. Just walk through cgroup file system and try to delete any cgroups which are marked consistent. ( basically try to reclaim all the persistent cgroups). Thanks Vivek ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
