|
|
| Next: Bug#421527: hdparm_7.1-1(hppa/unstable): FTBFS: b.. |
| Author |
Message |
Tom Laermans External

Since: Jan 28, 2005 Posts: 8
|
Posted: Sun Apr 29, 2007 11:10 pm Post subject: Bug#421524: snmpd uses 100% cpu Archived from groups: linux>debian>bugs>rc (more info?) |
|
|
Package: snmpd
Version: 5.2.3-7
Severity: grave
Justification: renders package unusable
snmpd is running at 100% CPU on 2 of my systems, and will not respond to
polls. I have tried the default config file, which has the same effect.
After restarting the daemon I can snmpwalk up to (ip's modified):
IP-MIB::ipAdEntBcastAddr.127.0.0.1 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.172.16.0.1 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.192.168.35.4 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.1.2.3.4 = INTEGER: 1
IP-MIB::ipAdEntBcastAddr.1.2.3.5 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.1.2.3.6 = INTEGER: 0
IP-MIB::ipAdEntBcastAddr.1.2.3.7 = INTEGER: 1
Timeout: No Response from sys.tem.host.name
After this the daemon goes to full CPU in a loop, strace loops this:
gettimeofday({1177879788, 679826}, NULL) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 14
open("/proc/net/dev", O_RDONLY) = 15
fstat64(15, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7f01000
read(15, "Inter-| Receive "..., 1024) = 1024
ioctl(14, SIOCGIFADDR, {ifr_name="lo", ifr_addr={AF_INET,
inet_addr("127.0.0.1")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="lo", ifr_broadaddr={AF_INET,
inet_addr("0.0.0.0")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="lo", ifr_netmask={AF_INET,
inet_addr("255.0.0.0")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="lo",
ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="lo", ifr_hwaddr=00:00:00:00:00:00}) = 0
ioctl(14, SIOCGIFMETRIC, {ifr_name="lo", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="lo", ifr_mtu=16436}) = 0
ioctl(14, SIOCGIFADDR, {ifr_name="dummy0", ifr_addr={AF_INET,
inet_addr("172.16.0.1")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="dummy0", ifr_broadaddr={AF_INET,
inet_addr("172.16.255.255")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="dummy0", ifr_netmask={AF_INET,
inet_addr("255.255.0.0")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="dummy0",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_NOARP}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="dummy0", ifr_hwaddr=12:8a:75:61:f9:64})
= 0
ioctl(14, SIOCGIFMETRIC, {ifr_name="dummy0", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="dummy0", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name="eth0", ifr_addr={AF_INET,
inet_addr("1.2.3.7")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="eth0", ifr_broadaddr={AF_INET,
inet_addr("1.2.3.8")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="eth0", ifr_netmask={AF_INET,
inet_addr("255.255.255.128")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="eth0",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="eth0", ifr_hwaddr=00:e0:81:04:5b:2c}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="eth0", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="eth0", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name="eth1", ifr_addr={AF_INET,
inet_addr("192.168.35.4")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="eth1", ifr_broadaddr={AF_INET,
inet_addr("192.168.35.255")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="eth1", ifr_netmask={AF_INET,
inet_addr("255.255.255.0")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="eth1",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="eth1", ifr_hwaddr=00:e0:81:04:5b:2d}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="eth1", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="eth1", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name="eth2", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFBRDADDR, {ifr_name="eth2", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFNETMASK, {ifr_name="eth2", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFFLAGS, {ifr_name="eth2",
ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:03:47:08:45:ce}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="eth2", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="eth2", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
ioctl(14, SIOCGIFADDR, {ifr_name="eth3", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFBRDADDR, {ifr_name="eth3", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFNETMASK, {ifr_name="eth3", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFFLAGS, {ifr_name="eth3",
ifr_flags=IFF_BROADCAST|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="eth3", ifr_hwaddr=00:03:47:08:45:cf}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="eth3", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="eth3", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
read(15, " 0 0 0 0 0 "..., 1024) = 298
read(15, " 0 0 0 0 0 "..., 1024) = 298
ioctl(14, SIOCGIFADDR, {ifr_name="sit0", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFBRDADDR, {ifr_name="sit0", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFNETMASK, {ifr_name="sit0", ???}) = -1 EADDRNOTAVAIL (Cannot
assign requested address)
ioctl(14, SIOCGIFFLAGS, {ifr_name="sit0", ifr_flags=IFF_NOARP}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="sit0", ifr_hwaddr=00:00:00:00:00:00}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="sit0", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="sit0", ifr_mtu=1480}) = 0
ioctl(14, SIOCGIFADDR, {ifr_name="tun0", ifr_addr={AF_INET,
inet_addr("1.2.3.4")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="tun0", ifr_broadaddr={AF_INET,
inet_addr("0.0.0.0")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="tun0", ifr_netmask={AF_INET,
inet_addr("255.255.255.252")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="tun0",
ifr_flags=IFF_UP|IFF_POINTOPOINT|IFF_RUNNING|IFF_NOARP|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="tun0", ifr_hwaddr=00:00:00:00:00:00}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="tun0", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="tun0", ifr_mtu=1500}) = 0
ioctl(14, SIOCGIFADDR, {ifr_name="tap0", ifr_addr={AF_INET,
inet_addr("1.2.3.5")}}) = 0
ioctl(14, SIOCGIFBRDADDR, {ifr_name="tap0", ifr_broadaddr={AF_INET,
inet_addr("1.2.3.6")}}) = 0
ioctl(14, SIOCGIFNETMASK, {ifr_name="tap0", ifr_netmask={AF_INET,
inet_addr("255.255.255.240")}}) = 0
ioctl(14, SIOCGIFFLAGS, {ifr_name="tap0",
ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0
ioctl(14, SIOCGIFHWADDR, {ifr_name="tap0", ifr_hwaddr=42:c7:5b:3a:e4:64}) =
0
ioctl(14, SIOCGIFMETRIC, {ifr_name="tap0", ifr_metric=0}) = 0
ioctl(14, SIOCGIFMTU, {ifr_name="tap0", ifr_mtu=1500}) = 0
ioctl(14, SIOCGMIIPHY, 0xbff15f38) = -1 EPERM (Operation not permitted)
ioctl(14, SIOCDEVPRIVATE, 0xbff15f38) = -1 EOPNOTSUPP (Operation not
supported)
read(15, "", 1024) = 0
close(15) = 0
munmap(0xb7f01000, 4096) = 0
close(14) = 0
ad infinitum.
Particular at these 2 systems is they both have a full routing table:
# ip route ls|wc -l
217705
I don't know if that has any influence.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.19.1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages snmpd depends on:
ii adduser 3.102 Add and remove users and groups
ii debconf 1.5.11 Debian configuration management sy
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
ii libsensors3 1:2.10.1-3 library to read temperature/voltag
ii libsnmp9 5.2.3-7 NET SNMP (Simple Network Managemen
ii libwrap0 7.6.dbs-13 Wietse Venema's TCP wrappers libra
snmpd recommends no packages.
-- debconf information:
snmpd/upgradefrom36:
* snmpd/upgradefrom521:
--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org |
|
| Back to top |
|
 |
Jochen Friedrich External

Since: Nov 12, 2004 Posts: 121
|
Posted: Wed May 02, 2007 1:00 pm Post subject: Bug#421524: [Pkg-net-snmp-devel] Bug#421524: snmpd uses 100% cpu [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
Hi Tom,
> snmpd is running at 100% CPU on 2 of my systems, and will not respond to
> polls. I have tried the default config file, which has the same effect.
I suspect this could be an upstream problem.
Do you have the chance to take 5.3.1-3 (from SID) or 5.4~dfsg-1 (from experimental) and recompile it on Etch?
It should recompile without any change.
Thanks,
Jochen
--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST.DeleteThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.DeleteThis@lists.debian.org |
|
| Back to top |
|
 |
Tom Laermans External

Since: Jan 28, 2005 Posts: 8
|
Posted: Sat May 05, 2007 4:40 pm Post subject: Bug#421524: [Pkg-net-snmp-devel] Bug#421524: snmpd uses 100% cpu [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
On Wed, 2007-05-02 at 12:49 +0200, Jochen Friedrich wrote:
> Hi Tom,
>
> > snmpd is running at 100% CPU on 2 of my systems, and will not respond to
> > polls. I have tried the default config file, which has the same effect.
>
> I suspect this could be an upstream problem.
I must add to the previous bugreport that actual polling of values does
work as long as one does not touch the sensitive ones (interface data I
think?).
> Do you have the chance to take 5.3.1-3 (from SID) or 5.4~dfsg-1 (from experimental) and recompile it on Etch?
> It should recompile without any change.
Tried the sid package, same effect.
Had previously tried 5.2.1.2-4ubuntu2.1 also, but that didn't help.
Now tried the experimental package, same effect.
Tom
--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org |
|
| Back to top |
|
 |
Jochen Friedrich External

Since: Nov 12, 2004 Posts: 121
|
Posted: Tue Aug 07, 2007 4:30 pm Post subject: Bug#421524: [Pkg-net-snmp-devel] Bug#421524: snmpd uses 100% cpu [Login to view extended thread Info.] Archived from groups: per prev. post (more info?) |
|
|
severity important
tags +upstream
thanks
Hi,
> snmpd is running at 100% CPU on 2 of my systems, and will not respond to
> polls. I have tried the default config file, which has the same effect.
This is also documented upstream at
http://sourceforge.net/tracker/index.php?func=detail&aid=1033342&group...=12694&
and
http://sourceforge.net/tracker/index.php?func=detail&aid=465161&group_...12694&a
To eliminate the ipRouteTable at startup, add "-I -var_route" to your command line arguments
in /etc/default/snmpd and poll ipCidrRouteTable or inetCidrRouteTable instead.
Thanks,
Jochen
--
To UNSUBSCRIBE, email to debian-bugs-rc-REQUEST.RemoveThis@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.RemoveThis@lists.debian.org |
|
| Back to top |
|
 |
|
|