On Thu, Sep 15, 2011 at 10:59:36AM +0200, Jan Safranek 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.
Ok, so what's the syntax of setting sticky bit using fperm? Also by default cgconfig means persistent groups. So I really don't expect users to set this bit explicitly using fperm in cgconfig.conf. This probably should be done automatically. > > >> 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. I was reading LWN article. http://lwn.net/Articles/458532/ And according to this there are other distributions which are planning to adopt systemd. So I don't think that it it is just Fedora. Down the line we might have a scenario where other use it too. In fact, what's the harm in setting sticky bit by default? Will something be broken with distributions not using systemd? >Anyway, it's just > one parameter in (distro specific) init script/unit file. Agreed that it is just one parameter. So even if you keep it otherwise I am fine. [..] > > 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. Ok. That's fine. So then we can maintain some kind of file which has list of groups created by cgconfig and we try to reclaim those groups when service is stopped. 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
