[ovs-discuss] openvswitch udev event flood

[Flavio Leitner]

On Wed, Sep 10, 2014 at 08:00:15PM -0700, Krishna Sagiraju wrote:
> I tried the suggestions. Please see my comments inline.
> 
> --Krishna/.
> 
> On 9/8/14, 11:59 AM, Flavio Leitner wrote:
> >On Mon, Sep 08, 2014 at 09:34:03AM -0700, Gurucharan Shetty wrote:
> >>I saw something similar today. In my case, 'force-reload-kmod' would
> >>trigger the udev event loop. Adding HOTPLUG=no in
> >>/etc/sysconfig/network-scripts/ifcfg-* solved the problem for me. I do
> >>not know the exact sequence of events that makes udev act that way.
> >>
> >>Here is one bug report where the end result is the same but the
> >>trigger is different.
> >>https://bugzilla.redhat.com/show_bug.cgi?id=855107
> >
> >There might be some scenarios where the hotplug event can trigger
> >a slave device which depends on the master which depends on something
> >that causes a loop.  The HOTPLUG=no on ports/slaves usually helps to
> >break such loops.
> Adding this to ifcfg-br-eth1 stopped the spew almost instantaneously.
> I didn't have to restart any service.

Ok, so it seems you have a work around at least.

> >I don't recall anything apart of OpenStack monitoring for openvswitch
> >module to load in the system.  Even if you load openvswitch, it should
> >not create any device by default.  However, if you restart the service
> >with 'stale' devices in the DB, the hotplug event will be fired. Maybe
> >that is confusing the agent.
> >
> >My suggestion to understand this better  would be to change
> >/etc/rc.d/init.d/openvswitch to capture additional info about
> >which pid is the parent, etc. For example, inserting those
> >3 'echo' lines below.
> >
> >#!/bin/bash
> >#
> >
> >echo "Parent: $(cat /proc/$PPID/cmdline) " >> /tmp/ovs.loop
> >echo "pid: $PPID, command line $*" >> /tmp/ovs.loop
> >echo "pstree: $(pstree -a -l -n)" >> /tmp/ovs.loop
> This didn't give much. In my case, the puppet was doing the installation.
> So,
> by the time, I got to add these the service is already started and there is
> nothing
> from this afterwards.

That's good info. We know the service is not being restarted.
As a next step, you could add the same lines to ifup script
which is used to bring up each device. That might give us a clue.

fbl