On Wed, Sep 7, 2011 at 12:41 AM, Vivek Goyal <[email protected]> wrote: > On Thu, Aug 25, 2011 at 07:14:56PM +0200, Lennart Poettering wrote: >> On Thu, 25.08.11 11:40, Vivek Goyal ([email protected]) wrote: >> >> > >> > On Tue, Aug 23, 2011 at 09:17:32PM +0200, Lennart Poettering wrote: >> > > On Tue, 23.08.11 11:20, Dhaval Giani ([email protected]) 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?
Yes, it does > 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. > Good point, we thought of global notifications, but we need to split the code to become client-server like udev to make that happen. > Am I missing something obivirous. Not sure I understand your proposal completely in terms of deregistering handlers Balbir ------------------------------------------------------------------------------ Using storage to extend the benefits of virtualization and iSCSI Virtualization increases hardware utilization and delivers a new level of agility. Learn what those decisions are and how to modernize your storage and backup environments for virtualization. http://www.accelacomm.com/jaw/sfnl/114/51434361/ _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
