comments inline.
--Krishna/.
On 9/11/14, 10:03 AM, Flavio Leitner wrote:
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.
I did instrument ifup-ovs when I originally raised the issue. All I was
there was that udevadm was the parent.
fbl
_______________________________________________
discuss mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/discuss
