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.
>>> 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?
Jan
------------------------------------------------------------------------------
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
