On Thu, Sep 15, 2011 at 2:29 PM, Jan Safranek <jsafr...@redhat.com> wrote: > On 09/14/2011 10:51 PM, Vivek Goyal wrote: >> 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. > > It has not been released yet, it's in git only. >
Hold on, won't namespaces solve the problem we are discussing? >>> 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. > > I think the sticky bit will be used in minority of use cases, Fedora > will be probably the only distro which will use it. Anyway, it's just > one parameter in (distro specific) init script/unit file. > >>> >>> 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? > > Yes, but that's why we have this thread to agree on different (and > better) behavior. > >> 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). > > IMHO the sticky bit should not be taken into account in all cases, any > app can change it, even the admin... I might add an option to cgclear to > either delete all 'sticky' groups or read cgconfigparser's backlog and > let distros decide what they prefer. I am not a big fan of the sticky bit either Balbir ------------------------------------------------------------------------------ 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
