On 02/14/2013 07:57 AM, Dhaval Giani wrote:
>
>
>
> On Thu, Feb 14, 2013 at 4:02 AM, Jan Safranek <jsafr...@redhat.com
> <mailto: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).
>
Right. In our case we have a daemon monitoring the DCB netlink events
creating net_prio control groups as needed.
> >>> 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.
>
Yes the process can change groups. Typically this would be moving from
a default group to a more specific one or vice versa.
The problem with delaying the execing/forking of the process is we don't
control the processes we are managing. Typically we are managing
standard network daemons iscsid is a common one for example. iscsid runs
in the default group until a network event occurs to trigger the
creation of the iscsi control group. From a high level the event is
telling us to run iSCSI traffic over some priority. The daemon
listening for these events creates the net_prio control group and then
any applications bound to the iscsi control group in cgrules.conf should
be moved accordingly. If we get an event to move iSCSI traffic back to
the default priority we simply delete the control group directory. But
we don't know when the event will come if it all so we can't block
iscsid waiting for the event.
Thanks,
John
> Dhaval
--
John Fastabend Intel Corporation
------------------------------------------------------------------------------
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
