On Thu, Aug 25, 2011 at 07:14:56PM +0200, Lennart Poettering wrote: > On Thu, 25.08.11 11:40, Vivek Goyal (vgo...@redhat.com) wrote: > > > > > On Tue, Aug 23, 2011 at 09:17:32PM +0200, Lennart Poettering wrote: > > > On Tue, 23.08.11 11:20, Dhaval Giani (dhaval.gi...@gmail.com) wrote: > > > > > > > > It is a relatively lose model. If that's the goal, then things are > > > > > fine. But I don't think that's the goal you had started with. > > > > > > > > Actually the original plan was this itself. The persistent stuff is > > > > stored by cgconfig, and the non persistent stuff can be created on the > > > > fly. We can always treat systemd as non-persistent and not bother > > > > about it. > > > > > > Yupp, that's how I like to see it. > > > > > > In fact, the sticky bit thing is probably what should be used to > > > distuingish persistant and volatile cgroups. libvrit and systemd should > > > create their groups without that bit, and delete their groups if the bit > > > is not set. cgconfig should set the bit to tell systemd/libvirt that a > > > specific cgroups should be considered persistant and not be deleted by > > > systemd/libvirtd. > > > > Or the subsystem who is responsible for creating cgroup should be > > responsible for deleting it (if need be). So if libvirt and systemd > > can check for presence of group and register removal handler only > > if group was freshly created, that should help too? > > Nah, that would be racy. If cgconfig happens to run first but later > restarted it would remove cgroups systemd mit still need. Note that > systemd creates cgroups when it starts services, which might race > against cgconfig.
[ Note: A very late response to an old mail...] Does cgconfig service deletes all the already created cgroup upon restart? If yes, how would sticky bit solve above race? If restarting the cgconfig service is trying to delete the groups which it created to begin with, same should be problem with sticky bit too. (cgconfig should have marked persistent groups with sticky bit set and would try to remove these upon restart). I think in this case cgconfig should just deregister the handler and let the cgroup be there is there is a service/task already running in the cgroup. (Anyway cgroup can't be deleted if something is running in it). And that should take care of above race. Am I missing something obivirous. Thanks Vivek ------------------------------------------------------------------------------ Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
