Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
Thanks a lot! Adrian
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
Thank you! Adrian
On 11/11/2020 19:10, Adrian Sevcenco wrote:
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
That appears to have been built already.
libteam-1.31-2.fc32 https://koji.fedoraproject.org/koji/buildinfo?buildID=1634489
You could grab the rpm from there and give it a try.
--- The key to getting good answers is to ask good questions.
On 11/11/2020 19:10, Adrian Sevcenco wrote:
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
A bit more.....
The BZ you reference says....
Yeah, libteam-1.31-2.el8.x86_64 works well! Could you do proper build?
In F32, dnf info shows
Name : libteam Version : 1.31 Release : 2.fc32 Architecture : x86_64 Size : 50 k Source : libteam-1.31-2.fc32.src.rpm Repository : updates Summary : Library for controlling team network device URL : http://www.libteam.org License : LGPLv2+ Description : This package contains a library which is a user-space : counterpart for team network driver. It provides an API : to control team network devices.
--- The key to getting good answers is to ask good questions.
On 11/11/20 1:43 PM, Ed Greshko wrote:
On 11/11/2020 19:10, Adrian Sevcenco wrote:
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
A bit more.....
The BZ you reference says....
so, now it appeared in updates and after upgrade it seems that the bug is not solved, and after a fresh reboot i see this :
[root@vbox1 ~]# ps -C teamd -o pid,pcpu,pmem,cmd PID %CPU %MEM CMD 1143 99.2 0.0 /usr/bin/teamd -o -n -U -D -N -t team0 -c {"runner": {"name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"]}}
[root@vbox1 ~]# uptime 01:44:58 up 14 min, 1 user, load average: 1.00, 0.98, 0.67
[root@vbox1 ~]# rpm -qa | grep libteam libteam-1.31-2.fc32.x86_64
Any ideas about this?
Thanks a lot! Adrian
Yeah, libteam-1.31-2.el8.x86_64 works well! Could you do proper build?
In F32, dnf info shows
Name : libteam Version : 1.31 Release : 2.fc32 Architecture : x86_64 Size : 50 k Source : libteam-1.31-2.fc32.src.rpm Repository : updates Summary : Library for controlling team network device URL : http://www.libteam.org License : LGPLv2+ Description : This package contains a library which is a user-space : counterpart for team network driver. It provides an API : to control team network devices.
The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
On 12/11/2020 07:46, Adrian Sevcenco wrote:
On 11/11/20 1:43 PM, Ed Greshko wrote:
On 11/11/2020 19:10, Adrian Sevcenco wrote:
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
A bit more.....
The BZ you reference says....
so, now it appeared in updates and after upgrade it seems that the bug is not solved, and after a fresh reboot i see this :
[root@vbox1 ~]# ps -C teamd -o pid,pcpu,pmem,cmd PID %CPU %MEM CMD 1143 99.2 0.0 /usr/bin/teamd -o -n -U -D -N -t team0 -c {"runner": {"name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"]}}
[root@vbox1 ~]# uptime 01:44:58 up 14 min, 1 user, load average: 1.00, 0.98, 0.67
[root@vbox1 ~]# rpm -qa | grep libteam libteam-1.31-2.fc32.x86_64
Any ideas about this?
Sorry, I don't. I don't use teamd. I was just assisting acquisition of the lib.
Suggest you add to that BZ that the problem still exists on Fedora 32 with the version of the lib installed.
--- The key to getting good answers is to ask good questions.
On 11/12/20 2:33 AM, Ed Greshko wrote:
On 12/11/2020 07:46, Adrian Sevcenco wrote:
On 11/11/20 1:43 PM, Ed Greshko wrote:
On 11/11/2020 19:10, Adrian Sevcenco wrote:
On 11/11/20 10:22 AM, Adrian Sevcenco wrote:
Hi! I have a strange situation where my teamd process take 100% processor without having any kind of traffic (beside my ssh connection)
I thought that is a NM problem and i disabled the connectivity check of NM .. does anyone encountered this and have any idea of the problem?
so, i found what is going on: https://bugzilla.redhat.com/show_bug.cgi?id=1874001
are there any plans to re-build/update the team packages? i see that there is none in testing ...
A bit more.....
The BZ you reference says....
so, now it appeared in updates and after upgrade it seems that the bug is not solved, and after a fresh reboot i see this :
[root@vbox1 ~]# ps -C teamd -o pid,pcpu,pmem,cmd PID %CPU %MEM CMD 1143 99.2 0.0 /usr/bin/teamd -o -n -U -D -N -t team0 -c {"runner": {"name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"]}}
[root@vbox1 ~]# uptime 01:44:58 up 14 min, 1 user, load average: 1.00, 0.98, 0.67
[root@vbox1 ~]# rpm -qa | grep libteam libteam-1.31-2.fc32.x86_64
Any ideas about this?
Sorry, I don't. I don't use teamd. I was just assisting acquisition of the lib.
Suggest you add to that BZ that the problem still exists on Fedora 32 with the version of the lib installed.
Sure, thanks a lot for your help!!! But i have to report that after another update of the host and a reboot the problem was really solved ... i'm not sure but i think that even the kernel was updated so i rally cannot pin-point the exact solution...
Once again, thanks a lot! Adrian
On 12/11/2020 16:14, Adrian Sevcenco wrote:
Sure, thanks a lot for your help!!! But i have to report that after another update of the host and a reboot the problem was really solved ... i'm not sure but i think that even the kernel was updated so i rally cannot pin-point the exact solution...
Once again, thanks a lot!
As long as it is fixed now. :-) :-) Welcome.
--- The key to getting good answers is to ask good questions.