On Fri, Nov 29, 2019 at 9:34 AM Michal Koutný <mkou...@suse.com> wrote:
> On Wed, Nov 20, 2019 at 02:01:24PM -0700, Tom Hromatka < > tom.hroma...@oracle.com> wrote: > > This patchset adds an options column to cgrules config file > > parsing. Within this column, a user can specify an "ignore" > > option that will instruct cgrules to ignore processes that > > exactly match this rule and perform no processing on these > > processes. > Interesting approach. IIUC, the ignore rules make sense only when a > superset rule exists. (Likely the universal '*' collector rule.) > > Not really. The ignore rules make sense when you have cgroups that are controlled by a third party entity and you do not want to modify the participants of that cgroup. > > > It is anticipated that a separate process - outside of cgrulesengd - > > will be used to manage processes that match ignore rules. > What would be an example ruleset to play along with the systemd > hieararchy? (I can't think of a good one right now, unless systemd is > put under a dedicated subtree.) > > > We have a few, completely unrelated to systemd. > > <user> <controller> <destination> <options> > > * cpu IgnoreCG/* ignore > > * cpu DefaultCgroup > > > > For the above example: > > * Any new processes spawned within the IgnoreCG or a child > > cgroup within IgnoreCG will be ignored by cgrulesengd > Is the wildcard over destination cgroup necessary? I'm thinking of a > rule with destination a/b/c would simply mean whole subtree of a/b/c. Or > is there a reasonable case when a/b/c should be ignored but a/b/c/d > should still be processed? > > Aha, good point, and I think I agree with you there. Dhaval _______________________________________________ Libcg-devel mailing list Libcg-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libcg-devel
