[ovs-dev] [PATCH] ovs-vsctl: Change log level of vsctl_parent_process_info

[Kyle Mestery]

On Thu, Aug 4, 2016 at 12:56 PM, Andy Zhou <azhou at ovn.org> wrote:
>
>
> On Thu, Aug 4, 2016 at 6:54 AM, Kyle Mestery <mestery at mestery.com> wrote:
>>
>> While running the ovn-scale-test [1] port-binding tests [2], I notice a
>> continual stream of messages such as this:
>>
>> 2016-08-04 13:05:28.705 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_cikzNO to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>> 2016-08-04 13:05:28.712 547 INFO paramiko.transport [-] Connected (version
>> 2.0, client OpenSSH_6.6.1p1)
>> 2016-08-04 13:05:28.805 547 INFO paramiko.transport [-] Authentication
>> (publickey) successful!
>> 2016-08-04T13:05:28Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04 13:05:29.042 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_tvovcK to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04 13:05:29.285 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_HwG7AK to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04 13:05:29.505 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_Lqbv92 to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04 13:05:29.724 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_6f8uQW to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04T13:05:29Z|00002|vsctl|WARN|/proc/0/cmdline: open failed (No
>> such file or directory)
>> 2016-08-04 13:05:29.944 547 INFO rally_ovs.plugins.ovs.scenarios.ovn [-]
>> bind lport_0996bf_nKl2XF to sandbox-172.16.200.24 on
>> ovn-farm-node-uat-dal09-compute-325
>>
>> Tracing these down, this is due to the check in
>> vsctl_parent_process_info(),
>> which is verifying if the parent process can be opened. Since
>> ovn-scale-test
>> runs sandboxes in containers, and these are run as root, there is no
>> /proc/0
>> in the container. Thus, the check fails, and the error message is printed
>> out.
>> Lowering the log level here results in less logs being dumped for this
>> failure
>> as ovn-scale-test runs.
>>
>> [1] https://github.com/openvswitch/ovn-scale-test
>> [2]
>> https://github.com/openvswitch/ovn-scale-test/blob/master/rally_ovs/plugins/ovs/scenarios/ovn.py#L255
>>
>> Signed-off-by: Kyle Mestery <mestery at mestery.com>
>> ---
>>  utilities/ovs-vsctl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/utilities/ovs-vsctl.c b/utilities/ovs-vsctl.c
>> index 722dcd9..56f1906 100644
>> --- a/utilities/ovs-vsctl.c
>> +++ b/utilities/ovs-vsctl.c
>> @@ -2483,7 +2483,7 @@ vsctl_parent_process_info(void)
>>
>>      f = fopen(procfile, "r");
>>      if (!f) {
>> -        VLOG_WARN("%s: open failed (%s)", procfile, ovs_strerror(errno));
>> +        VLOG_DBG("%s: open failed (%s)", procfile, ovs_strerror(errno));
>>          free(procfile);
>>          return NULL;
>>      }
>> --
>> 2.7.4 (Apple Git-66)
>>
>> _______________________________________________
>> dev mailing list
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev
>
>
> I wonder if we should log it at all if not being able to proc file can be
> expected in real life.

I'm fine with that approach as well, I can spin another patch.