[2.2.2] Primary Interface Not Being Picked Up And Constantly Looping

[ghost]

This morning a production issue happened on one of our Linux VMs and I was unable to SSH into the box. I had to restart the VM through the Azure portal. After the restart, I was able to SSH in and saw a lot of entries in the logs before the restart.

2017/03/08 13:07:09.163569 INFO examine /proc/net/route for primary interface
2017/03/08 13:07:09.188843 INFO primary interface is []
2017/03/08 13:07:09.214510 INFO interface [b'lo'] has flags [73], is loopback [True]
2017/03/08 13:07:09.236816 INFO interface [b'lo'] skipped
2017/03/08 13:07:09.252286 INFO interface [b''] skipped
2017/03/08 13:07:09.273264 INFO interface [b''] skipped
2017/03/08 13:07:09.292313 INFO interface [b''] skipped
2017/03/08 13:07:09.305719 INFO interface [b''] skipped
2017/03/08 13:07:09.315439 INFO interface [b''] skipped
2017/03/08 13:07:09.330950 INFO interface [b''] skipped
2017/03/08 13:07:09.353131 INFO interface [b''] skipped
2017/03/08 13:07:09.363266 INFO interface [b''] skipped
2017/03/08 13:07:09.375869 INFO interface [b''] skipped
2017/03/08 13:07:09.401768 INFO interface [b''] skipped
2017/03/08 13:07:09.439751 INFO interface [b''] skipped
2017/03/08 13:07:09.453651 INFO interface [b''] skipped
2017/03/08 13:07:09.470809 INFO interface [b''] skipped
2017/03/08 13:07:09.485603 INFO interface [b''] skipped
2017/03/08 13:07:09.506423 INFO interface [b''] skipped
2017/03/08 13:07:09.528646 INFO examine /proc/net/route for primary interface

I think the logging was eating up the resources potentially since it was adding an entry every few microseconds.

I ran the get_primary_interface code from https://github.com/Azure/WALinuxAgent/blob/master/azurelinuxagent/common/osutil/default.py in a Python script to test on the box and it returned "primary interface is [eth0]."

If someone could enlighten me what's happening that would be great! I think this happened before but I never bothered to look into it until now.

The operating system is Ubuntu 16.04 with Python 3.5.2.

[brendandixon]

@colinmc Without the /proc/net/routes file it's hard to tell why the code failed. Perhaps we should emit a log message listing that file for diagnostics in case this recurs.

[ghost]

@brendandixon Here's the file contents:

Iface	Destination	Gateway 	Flags	RefCnt	Use	Metric	Mask		MTU	Window	IRTT                                                       
eth0	00000000	0100010A	0003	0	0	0	00000000	0	0	0                                                                               
eth0	0000010A	00000000	0001	0	0	0	00FFFFFF	0	0	0                                                                               
eth0	10813FA8	0100010A	0007	0	0	0	FFFFFFFF	0	0	0                                                                               
eth0	FEA9FEA9	0100010A	0007	0	0	0	FFFFFFFF	0	0	0                                                               

[hglkrijger]

@colinmc The routing table is now valid, since the reboot likely fixed it via dhcp restart. #612 will log the invalid contents for future reference.