On Wed, Sep 07, 2011 at 07:48:41AM +0530, Balbir Singh wrote: > On Wed, Sep 7, 2011 at 12:41 AM, Vivek Goyal <vgo...@redhat.com> wrote: > > 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? > > Yes, it does
Ok, I just did some testing on 6.1 (no systemd there). I created a group, put a task in the group and called "service cgconfig stop". This seems to have moved my task to root group and then deleted the group and unmounted the hierarhies. I don't think this is going to work well with systemd. Think of a scenario where systemd service and cgconfig are sharing the group. In that case if cgconfig is stopped, I am assuming that systemd would want tasks in shared cgroup to be moved out and deleted. I think that's the problem we are trying to resolve that how to deal with shared cgroup where cgconfig does not reclaim the groups used by libvirt and systemd and vice-a-versa. With systemd, now mounting hierarchies will be done by systemd. So that part can be removed from cgconfig and cgconfig does not have to worry about unmounting hierarchies. Now only question left out is what to do with shared cgroups. I guess a less intrusive operation would be to let the cgroup be there if it is not empty and not try to reclaim it. Or create additional option in the service where if a user wants, things can be configured in such a way that all tasks are moved to root cgroup and cgconfig reclaims all the persistent cgroups it has created. It might not be a suitable default though. > > > 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 Actually I was thinking of using "release_agent" in a way that owner of the group registers the release_agent. But then I realized that release_agent seems to be per hiearchy in root group and not per cgroup. So it is out of the window. So setting sticky bit for persistent group can help with the case where libvirtd/systemd/xyz-manager does not try to remove persistent groups created by cgconfig. But it looks like it will not handle the case of cgconfig not removing groups shared by other services. I guess, not removing groups which have tasks running might be an acceptable solution but that leaves the problem that when cgroup is empty, who removes it. A release agent again? Thanks Vivek ------------------------------------------------------------------------------ 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 Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
