On Thu, Feb 14, 2013 at 4:02 AM, Jan Safranek <jsafr...@redhat.com> wrote:
> On 02/13/2013 05:31 PM, John Fastabend wrote:
> > On 02/13/2013 12:48 AM, Jan Safranek wrote:
> >> On 02/12/2013 08:11 PM, John Fastabend wrote:
> >>> To accomplish this track the watched directories in a list adding
> >>> additional directories and removing them as needed. When inotify
> >>> events are received scan the rules.conf file.
> >>
> >> I don't follow here. Event of 'creating control group' does not indicate
> >> that cgrules.conf has changed and should be reloaded. Shouldn't you
> >> watch the cgrules.conf file instead?
> >>
> >
> > In our use case we edit the cgrules.conf first then 'create control
> > group' later. The use case here is an administrator needs to come
> > in and bind applications to an application type and then later what
> > priority this should actually use is decided via networking protocols.
> >
> > A specific example might help. Take a webserver we don't actually know
> > what daemon the user might want to use before hand httpd, nginx,
> > lighttpd, etc. So we expect the administrator or pkg tools to create
> > an entry in cgrules.conf to bind the application to a known net_prio
> > control group. When the network protocol negotiates the priority to
> > use for http we then create the control group and assign the priority.
> > The cgrules.conf entry is already added so the webserver should
> > somehow be moved into this control group.
>
> If something (httpd.rpm) adds rule to cgrules.conf, how can it know to
> which group should it assign the httpd? The name of the group must be
> known before, i.e. it should be already in cgconfig.conf.
>
> Or, in other words, how does your application know, which cgroup to
> create? Because it must be already present in cgrules.conf, created by
> admin/the package and it may have whatever name the admin wants.
>
>
Well, its not necessary that cgconfig be used to create the cgroups. I
assume they use some other mechanism to create the cgroup (as opposed to
creating it apriori).
> >>> Without this adding control group after cgrulesengd has started
> >>> does not work correctly and processes running before cgrulesengd
> >>> is started are not managed.
> >>>
> >>> This allows for a couple use cases that I could not find a way to
> >>> handle without this infrastructure. First processes that are used
> >>> in initd time frame are run before cgrulesengd is started. Often
> >>> these are daemons that we would like to manage via control groups.
> >>>
> >>> Another example is the net_{cls|prio} cgroups. In these cases
> >>> we may be adding/removing groups somewhat dynamically based on
> >>> control protocols (DCBX) or user input. In the DCB case DCBX
> >>> negotiates what priority an application should use via
> >>> link layer discovery protocol (LLDP). Then we use control
> >>> groups to set this up but this usually happens after cgrulesengd
> >>> has started so prior to this happening we don't know which apps
> >>> and directories we need to support.
> >>
> >> If you add/remove cgroups dynamically, you should also add rules to
> >> cgrules.conf dynamically, so the daemon knows it should move something
> >> to the new groups. And if you modify cgrules.conf, you can also send
> >> SIGUSR2 to cgrulesengd to reload the rules.
> >
> > As described our flow is the other way around. However if we don't want
> > to monitor for create/delete events in the control group fs we can
> > have our application force a rescan basically doing what cgclassify
> > would do when we add the directory.
> >
> > I just thought this might be more generic but I'm fine with putting it
> > in my application. I guess the key point being we created/destroyed the
> > directory so we should deal with doing the classify step as well?
>
> I still consider it's weird to re-scan all processes just because a
> cgroup has been created/deleted. What about others? Dhaval? Balbir?
>
>
I had a question,
Can your process change groups? As in, is there always the same 1:1 mapping
of process to group, or can it change? If so, then since you already have
your rule in cgrules.conf, you just need to delay execing/forking the
process till after your group is created. This will allow cgrulesdaemon to
catch the process and put in correctly.
Dhaval
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
