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. >> 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. Jan ------------------------------------------------------------------------------ Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
