On Tue, Sep 20, 2011 at 1:32 PM, Jan Safranek <jsafr...@redhat.com> wrote: > On 09/20/2011 09:31 AM, Balbir Singh wrote: >>> >>> No, as Lennart stated earlier in this thread, systemd is limited to >>> create only simple hierarchies, for complex ones cgconfig should be used >>> to create and configure groups for services. So systemd and cgconfig >>> should cooperate in shared cgroup trees, they won't have separate subtrees. >>> >>
I was responding to Vivek's comments and so primarily addressing his concern > 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') I agree we need to cooperate on the shared cgroup trees, but that requires some fundamental changes like 1. Namespaces can be used to create the hierarchy at run time we need 1. Notification when a cgroup gets created (deletion we already got it, but we might need client specific notification) I am not sure what sort of pluggable policy would help us integrate with systemd, I guess we need systemd aware config files when the administrator is running with a system that has systemd. What else does everybody have in mind? Balbir ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
