I found this err in "loadbalance" and "lacp" runner when adding ports. It's caused by trying to set "enabled" option in .port_link_changed() or .port_changed().
When a new port is added, the first 'port changed event' process is earlier than CMD TEAM_CMD_OPTIONS_GET, in this CMD, all the options are synchronized from kernel.
It means there's no 'enabled' option yet when calling port_link_changed in the first 'port changed event' process. In lb_event_watch_port_link_changed and lacp_event_watch_port_changed, they call teamd_port_check_enable to set 'enabled' option. this err is triggered.
I'm not sure why teamd_port_check_enable needs to check if 'enabled' option exists. I checked the ab's .port_link_changed(), it just sets it by calling team_set_port_enabled(), instead of checking 'enabled' option first.
can we just use team_set_port_enabled to set it directly in .port(_link)_changed OR improve teamd_port_check_enable to avoid this err ?
Thanks.
Tue, Feb 07, 2017 at 05:03:32PM CET, lucien.xin@gmail.com wrote:
I found this err in "loadbalance" and "lacp" runner when adding ports. It's caused by trying to set "enabled" option in .port_link_changed() or .port_changed().
When a new port is added, the first 'port changed event' process is earlier than CMD TEAM_CMD_OPTIONS_GET, in this CMD, all the options are synchronized from kernel.
It means there's no 'enabled' option yet when calling port_link_changed in the first 'port changed event' process. In lb_event_watch_port_link_changed and lacp_event_watch_port_changed, they call teamd_port_check_enable to set 'enabled' option. this err is triggered.
I'm not sure why teamd_port_check_enable needs to check if 'enabled' option exists. I checked the ab's .port_link_changed(), it just sets it by calling team_set_port_enabled(), instead of checking 'enabled' option first.
So if the teamd_port_enabled fails, you would assume curr_enabled_state == false and continue on?
I would add a teamd_log_dbg print if that happens, but I don't see any problem in that.
can we just use team_set_port_enabled to set it directly in .port(_link)_changed OR improve teamd_port_check_enable to avoid this err ?
Thanks.
On Thu, Feb 16, 2017 at 5:39 PM, Jiri Pirko jiri@resnulli.us wrote:
Tue, Feb 07, 2017 at 05:03:32PM CET, lucien.xin@gmail.com wrote:
I found this err in "loadbalance" and "lacp" runner when adding ports. It's caused by trying to set "enabled" option in .port_link_changed() or .port_changed().
When a new port is added, the first 'port changed event' process is earlier than CMD TEAM_CMD_OPTIONS_GET, in this CMD, all the options are synchronized from kernel.
It means there's no 'enabled' option yet when calling port_link_changed in the first 'port changed event' process. In lb_event_watch_port_link_changed and lacp_event_watch_port_changed, they call teamd_port_check_enable to set 'enabled' option. this err is triggered.
I'm not sure why teamd_port_check_enable needs to check if 'enabled' option exists. I checked the ab's .port_link_changed(), it just sets it by calling team_set_port_enabled(), instead of checking 'enabled' option first.
So if the teamd_port_enabled fails, you would assume curr_enabled_state == false and continue on?
I'm thinking why ab runner doesn't need to check if 'enabled' option exists before setting it, ab's .port_link_changed just calls team_set_port_enabled directly.
can't we just do it for lb and lacp runner ? is there any special reason we should check if 'enabled' option exists first ?
I would add a teamd_log_dbg print if that happens, but I don't see any problem in that.
can we just use team_set_port_enabled to set it directly in .port(_link)_changed OR improve teamd_port_check_enable to avoid this err ?
Thanks.
Thu, Feb 16, 2017 at 01:45:37PM CET, lucien.xin@gmail.com wrote:
On Thu, Feb 16, 2017 at 5:39 PM, Jiri Pirko jiri@resnulli.us wrote:
Tue, Feb 07, 2017 at 05:03:32PM CET, lucien.xin@gmail.com wrote:
I found this err in "loadbalance" and "lacp" runner when adding ports. It's caused by trying to set "enabled" option in .port_link_changed() or .port_changed().
When a new port is added, the first 'port changed event' process is earlier than CMD TEAM_CMD_OPTIONS_GET, in this CMD, all the options are synchronized from kernel.
It means there's no 'enabled' option yet when calling port_link_changed in the first 'port changed event' process. In lb_event_watch_port_link_changed and lacp_event_watch_port_changed, they call teamd_port_check_enable to set 'enabled' option. this err is triggered.
I'm not sure why teamd_port_check_enable needs to check if 'enabled' option exists. I checked the ab's .port_link_changed(), it just sets it by calling team_set_port_enabled(), instead of checking 'enabled' option first.
So if the teamd_port_enabled fails, you would assume curr_enabled_state == false and continue on?
I'm thinking why ab runner doesn't need to check if 'enabled' option exists before setting it, ab's .port_link_changed just calls team_set_port_enabled directly.
can't we just do it for lb and lacp runner ? is there any special reason we should check if 'enabled' option exists first ?
The reason AB does this differently is that it does not have to check if the port was enabled before or not. On enable it is clear that the port is disabled and vice versa.
For lb/lacp we need to check. So my original suggestion still stands.
Thanks.
I would add a teamd_log_dbg print if that happens, but I don't see any problem in that.
can we just use team_set_port_enabled to set it directly in .port(_link)_changed OR improve teamd_port_check_enable to avoid this err ?
Thanks.
Hi,
Is it possible I am still seeing this in Fedora 30?
``` enp6s0: Failed to find "enabled" option. PRIORITY 3 SYSLOG_FACILITY 3 SYSLOG_IDENTIFIER teamd_team0 SYSLOG_PID 6784 SYSLOG_TIMESTAMP Sep 16 15:37:58 _BOOT_ID 78b4b5838624413e8bbb44bf100603b1 _CAP_EFFECTIVE 200534e2 _CMDLINE /usr/bin/teamd -o -n -U -D -N -t team0 -c {"device": "team0", "runner": {"name": "lacp", "fast_rate": true, "tx_hash": ["eth", "ipv4", "ipv6"]}, "link_watch": {"name": "ethtool"}, "ports": {"enp5s0": {}, "enp6s0": {}}} _COMM teamd _EXE /usr/bin/teamd _GID 0 _HOSTNAME arsenal.home.airey.be _MACHINE_ID 383f89bb029f4dec961190553e69def9 _PID 6784 _SELINUX_CONTEXT system_u:system_r:NetworkManager_t:s0 _SOURCE_REALTIME_TIMESTAMP 1568641078760662 _SYSTEMD_CGROUP /system.slice/NetworkManager.service _SYSTEMD_INVOCATION_ID 42b6b1fb5d6a439eb7944d5b9fb43640 _SYSTEMD_SLICE system.slice _SYSTEMD_UNIT NetworkManager.service _TRANSPORT syslog _UID 0 __CURSOR s=27890e66e8c548ebbcc98d13b15ea44c;i=2f614a;b=78b4b5838624413e8bbb44bf100603b1;m=e732545ad;t=592abb6479f60;x=140626a83a188bed __MONOTONIC_TIMESTAMP 62061364653 __REALTIME_TIMESTAMP 1568641078763360 ```
I am sorry -_-. It was a misconfiguration from my end.
For future reference: my team0 was set to "auto" as ipv4.method. But actually I am using a vlan interface on top of that which did DHCP, and no DHCP is available on the default VLAN. After setting the ipv4.method to "link-local", the messages disappeared from the logs. This was also causing some network hiccups on the host that now went away.
libteam@lists.fedorahosted.org
-
Andy Airey -
Jiri Pirko -
Xin Long