Bug#949719: ntopng missing startup depenency on redis-server in systemd
Package: ntopng Version: 3.8+dfsg1-2.1 There is a system boot race between ntopng and redis-server because ntopng doesn't have the dependency in the systemd config (it is present in init.d but not systemd) root@ganges:~# systemctl status ntopng ... Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:111] ERROR: ntopng requires redis server to be up and running Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:112] ERROR: Please start it and try again or use -r Jan 23 19:25:02 ganges ntopng[7891]: 23/Jan/2020 19:25:02 [Redis.cpp:113] ERROR: to specify a redis server other than the default root@ganges:~# systemctl status redis-server ... Jan 23 19:25:03 ganges systemd[1]: Started Advanced key-value store. Note ntopng was started prior to redis-server on server boot. root@ganges:~# grep redis /etc/init.d/ntopng # Required-Start:$remote_fs $syslog redis-server # Required-Stop: $remote_fs $syslog redis-server root@ganges:~# grep redis /etc/systemd/system/multi-user.target.wants/ntopng.service root@ganges:~# An 'After=redis-server.service' would seem approprate in ntopng.service -- Dave
Bug#842573: xserver-xorg-video-intel: Latest backport to jessie results in display corruption
Also seeing this. Every few days/weeks I start getting corruption of objects (messed up bitmaps, icons that are blank, background that doesn't clear/update), etc... running 2:2.99.917+git20161206-1~bpo8+1 on Broadwell-U (8086:1616) specifically on a Lenovo X1 Carbon 3rd gen. Problem doesn't happen on 2:2.21.15-2+b2, however that version doesn't support acceleration on Broadwell so everything is slow. [12.068] Current Operating System: Linux hermes 3.16.0-4-amd64 #1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19) x86_64 [12.068] xorg-server 2:1.16.4-1+deb8u1 (http://www.debian.org/support) -- Dave
Bug#816872: wmbattery: memory leak in wmbattery
Package: wmbattery Version: 2.45-2 Severity: important Dear Maintainer, wmbattery appears to have a memory leak. When invoked with "wmbattery -w 2" it is leaking approx 350KB/minute on my system. Eventually it runs out of memory and is killed by kernel. $ while sleep 300; do ps u $(pidof wmbattery); done USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.0 18524 6792 ?Sl 21:24 0:00 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 20068 7976 ?Sl 21:24 0:01 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 21604 9404 ?Sl 21:24 0:01 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 23160 10588 ?Sl 21:24 0:02 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 24696 12208 ?Sl 21:24 0:03 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 26164 14032 ?Sl 21:24 0:03 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.1 27700 15464 ?Sl 21:24 0:04 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.2 29644 17240 ?Sl 21:24 0:05 wmbattery -w 2 USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND davijoh3 29894 0.2 0.2 31180 18964 ?Sl 21:24 0:05 wmbattery -w 2 -- System Information: Debian Release: 8.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wmbattery depends on: ii libapm1 3.2.2-15 ii libc62.19-18+deb8u3 ii libglib2.0-0 2.42.1-1 ii libupower-glib3 0.99.1-3.2 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxpm4 1:3.5.11-1+b1 ii upower 0.99.1-3.2 wmbattery recommends no packages. Versions of packages wmbattery suggests: ii wmaker 0.95.5-2+b2 -- no debconf information
Bug#510495: memory profiler results
John Morrissey writes:
> The next step would probably involve running snmpd in debug mode and
> comparing the output to what's being done in the source. Poking at the
> functions in these backtraces with gdb(1) might be more productive.
something in ipAddressTable_cache_load() or more specifically
_check_entry_for_updates() looks like a problem.
with 100 vlans, and 103 total interfaces:
here's the progression in ipAddressTable_cache_load()
before _check_entry_for_updates iteration:
(gdb) call container->get_size(container)
$89 = 104
(gdb) call ipaddress_container->get_size(ipaddress_container)
$90 = 204
after _check_entry_for_updates iteration:
(gdb) call container->get_size(container)
$93 = 104
(gdb) call ipaddress_container->get_size(ipaddress_container)
$94 = 100
after _add_new_entry iteration:
(gdb) call container->get_size(container)
$96 = 104
(gdb) call ipaddress_container->get_size(ipaddress_container)
$97 = 100
the next call after the _add_new_entry is to free
ipaddress_container. the comment seems incorrect as there are still
100 entries in ipaddress_container.
/*
* free the container. we've either claimed each entry, or released it,
* so the access function doesn't need to clear the container.
*/
netsnmp_access_ipaddress_container_free(ipaddress_container,
NETSNMP_ACCESS_IPADDRESS_FREE_DONT_CLEAR);
Back at the beginning we see the 204 entries:
(gdb) p *(binary_array_table*)ipaddress_container->container_data
$107 = {max_size = 320, count = 204, flags = 0, dirty = 1, data_size = 4, data
= 0x8310638}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[0]
$111 = {oid_index = {len = 0x1, oids = 0x812fc30}, ns_ia_index = 0x1, flags =
0x0, ia_address = {0x7f, 0x0, 0x0, 0x1, 0x0 }, if_index =
0x1, ia_prefix_oid = 0x0, ia_address_len = 0x4, ia_prefix_oid_len = 0x0,
ia_type = 0x1, ia_status = 0x1, ia_origin = 0x2, ia_storagetype = 0x2,
arch_data = 0x8149b00}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[1]
$112 = {oid_index = {len = 0x1, oids = 0x811d948}, ns_ia_index = 0x2, flags =
0x0, ia_address = {0xa, 0xc8, 0xca, 0xec, 0x0 }, if_index =
0x2, ia_prefix_oid = 0x0, ia_address_len = 0x4, ia_prefix_oid_len = 0x0,
ia_type = 0x1, ia_status = 0x1, ia_origin = 0x2, ia_storagetype = 0x2,
arch_data = 0x8264438}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[2]
$113 = {oid_index = {len = 0x1, oids = 0x8130950}, ns_ia_index = 0x3, flags =
0x0, ia_address = {0xa, 0x2, 0x64, 0x1, 0x0 }, if_index =
0x3, ia_prefix_oid = 0x0, ia_address_len = 0x4, ia_prefix_oid_len = 0x0,
ia_type = 0x1, ia_status = 0x1, ia_origin = 0x2, ia_storagetype = 0x2,
arch_data = 0x812a660}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[3]
$114 = {oid_index = {len = 0x1, oids = 0x8136148}, ns_ia_index = 0x4, flags =
0x0, ia_address = {0xa, 0x2, 0x65, 0x1, 0x0 }, if_index =
0x4, ia_prefix_oid = 0x0, ia_address_len = 0x4, ia_prefix_oid_len = 0x0,
ia_type = 0x1, ia_status = 0x1, ia_origin = 0x2, ia_storagetype = 0x2,
arch_data = 0x812a418}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[4]
$115 = {oid_index = {len = 0x1, oids = 0x812fa20}, ns_ia_index = 0x5, flags =
0x0, ia_address = {0xa, 0x2, 0x66, 0x1, 0x0 }, if_index =
0x5, ia_prefix_oid = 0x0, ia_address_len = 0x4, ia_prefix_oid_len = 0x0,
ia_type = 0x1, ia_status = 0x1, ia_origin = 0x2, ia_storagetype = 0x2,
arch_data = 0x8131da0}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[102]
$122 = {oid_index = {len = 0x1, oids = 0x8166610}, ns_ia_index = 0x67, flags =
0x0, ia_address = {0x0 , 0x1}, if_index = 0x1, ia_prefix_oid
= 0x0, ia_address_len = 0x10, ia_prefix_oid_len = 0x0, ia_type = 0x1, ia_status
= 0x1, ia_origin = 0x2, ia_storagetype = 0x2, arch_data = 0x8166658}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[103]
$123 = {oid_index = {len = 0x1, oids = 0x8166690}, ns_ia_index = 0x68, flags =
0x0, ia_address = {0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x50, 0x54, 0x0,
0xff, 0xfe, 0x66, 0x0, 0x97}, if_index = 0x66, ia_prefix_oid = 0x0,
ia_address_len = 0x10, ia_prefix_oid_len = 0x0, ia_type = 0x1, ia_status = 0x1,
ia_origin = 0x5, ia_storagetype = 0x2, arch_data = 0x81666d8}
(gdb) p /x
*(netsnmp_ipaddress_entry*)((binary_array_table*)ipaddress_container->container_data)->data[104]
$124 = {oid_index = {len = 0x1, oids = 0x82fd680}, ns_ia_index = 0x69, flags =
0x0, ia_address = {0xfe, 0x80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x50, 0x54, 0x0,
0xff, 0xfe, 0x66, 0x0, 0x97}, if_index = 0x65, ia_prefix_oid = 0x0,
ia_address_len = 0x10, ia_prefix_oid_len = 0x0, ia_type = 0x1, ia_status = 0x1,
ia_o
Bug#510495: default install of snmpd leaks memory when VLAN interfaces present
Package: snmpd Version: 5.2.3-7etch4 Severity: important The default etch install of snmpd with default config will leak memory if there is 1 or more VLAN ethernet interfaces on the system. This appears to be a regression between sarge and etch. After some investigation I've found: * leak occurs every 60 seconds * leak occurs at a rate of 1094KB/day _per_ VLAN interface * rate of leak is directly proportional to the number of VLAN interfaces * leak occurs even if no snmp activity is happening (get, set, get next, trap, etc..) * the VLAN interface must have an IPv4 address assigned * the VLAN interface can be either UP or DOWN * the name of the VLAN interface doesn't matter How to recreate: apt-get install vlan add to /etc/network/interfaces: > iface eth0.100 inet static > address 10.2.100.1 > netmask 255.255.255.0 > broadcast 10.2.100.255 ifup eth0.100 watch snmpd grow... start of test: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND snmp 1886 0.0 0.7 6784 3860 ?S22:06 0:00 /usr/sbin/snmpd after 10 hours: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND snmp 1886 0.0 0.8 7300 4316 ?SJan01 0:00 /usr/sbin/snmpd To amplify the effect, configure 100 VLANs instead of just 1 100 vlans configured: start of test: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND snmp 4694 0.0 0.8 7184 4188 ?S09:16 0:00 /usr/sbin/snmpd after 20 minutes: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND snmp 4694 0.0 1.1 8732 5720 ?S09:16 0:00 /usr/sbin/snmpd -- 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.18-6-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages snmpd depends on: ii adduser3.102 Add and remove users and groups ii debconf1.5.11etch2 Debian configuration management sy ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii libsensors31:2.10.1-3library to read temperature/voltag ii libsnmp9 5.2.3-7etch4 NET SNMP (Simple Network Managemen ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra snmpd recommends no packages. -- debconf information: snmpd/upgradefrom521: snmpd/upgradefrom36: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#433543: ifconfig is missing IPv6 address for interfaces with ifindex > 255
Package: net-tools
Version: 1.60-17
Tags: patch
When running 'ifconfig' it will not show any IPv6 addresses for
interfaces that have an ifindex > 255.
Because the kernel will increment the ifindex every time an interface
is added or removed, it is not necessary to have 256 interfaces at
once, just creating 256 interfaces since system boot and they will no
longer show IPv6 addresses.
This is due to an improper fscanf() maximum range argument. Patch to
fix the problem is below.
Example:
st34:~# ip addr list dev eth1.110
268: [EMAIL PROTECTED]: mtu 1500 qdisc noqueue
link/ether 00:e0:81:2a:0d:2d brd ff:ff:ff:ff:ff:ff
inet6 fd4d:5643:2886:6e::ea:0/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::2e0:81ff:fe2a:d2d/64 scope link
valid_lft forever preferred_lft forever
st34:~# ifconfig eth1.110
eth1.110 Link encap:Ethernet HWaddr 00:E0:81:2A:0D:2D
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:676 (676.0 b)
st34:~# grep eth1.110 /proc/net/if_inet6
fd4d56432886006e00ea 10c 40 00 80 eth1.110
fe8002e081fffe2a0d2d 10c 40 20 80 eth1.110
st34:~#
--- lib/interface.c.orig2007-06-18 13:51:41.0 -0400
+++ lib/interface.c 2007-06-18 13:52:04.0 -0400
@@ -718,7 +718,7 @@
/* FIXME: should be integrated into interface.c. */
if ((f = fopen(_PATH_PROCNET_IFINET6, "r")) != NULL) {
- while (fscanf(f, "%4s%4s%4s%4s%4s%4s%4s%4s %02x %02x %02x %02x %20s\n",
+ while (fscanf(f, "%4s%4s%4s%4s%4s%4s%4s%4s %08x %02x %02x %02x %20s\n",
addr6p[0], addr6p[1], addr6p[2], addr6p[3],
addr6p[4], addr6p[5], addr6p[6], addr6p[7],
&if_idx, &plen, &scope, &dad_status, devname) != EOF) {
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
