Hello,
Alan Cox gave me this address to report a problem I'm seeing in
Linux 2.2.19. I have an old 486 box configured as a masquerading
firewall/web server/squid cache. It sits on a cablemodem and runs
pumpd to acquire a DHCP lease for our IP address.
It appears that every time pumpd renews our lease, the kernel leaks
about 200 skbuffs. I noticed this because the number of active
skbuff_heads shown in /proc/slabinfo seemed unusually large prior
to my last reboot (approx 180000).
I rebooted, and then set up a cron job to monitor the "skbuff_head_cache"
line in /proc/slabinfo every 5 minutes, so I could correlate the
increases back to a specific event. (Prior to that, I had tried
to trigger a leak by exercising the various services on the box,
such as the squid cache, etc. with no success.) I discovered that
the number of active skbuff_head's would increase by 200 or so
around the same time as pumpd would renew my lease:
/var/log/messages:
Sep 30 23:32:33 asylum pumpd[215]: renewed lease for interface eth0
Oct 1 04:47:37 asylum pumpd[215]: renewed lease for interface eth0
/var/log/skbuff_head.log: (my adhoc "grep skbuff_head >> log" script)
Sun Sep 30 23:30:00 CDT 2001 skbuff_head_cache 1010 1058
Sun Sep 30 23:35:00 CDT 2001 skbuff_head_cache 1066 1081
Sun Sep 30 23:40:00 CDT 2001 skbuff_head_cache 1211 1219
Sun Sep 30 23:45:00 CDT 2001 skbuff_head_cache 1288 1311
...
Mon Oct 1 04:45:00 CDT 2001 skbuff_head_cache 1290 1311
Mon Oct 1 04:50:00 CDT 2001 skbuff_head_cache 1299 1311
Mon Oct 1 04:55:00 CDT 2001 skbuff_head_cache 1355 1357
Mon Oct 1 05:00:00 CDT 2001 skbuff_head_cache 1447 1449
Mon Oct 1 05:05:00 CDT 2001 skbuff_head_cache 1475 1495
It appears that right after the lease is renewed, other traffic seems
to leak skbuffs.
It's probably worth describing what other sorts of connections are
open on the box most of the time (and most importantly, are live
across a DCHP lease renewal, which might be why I leak skbuffs after
a renewal):
-- I typically have one or two rsh connections open to the box
from another box on the local LAN.
-- I have a Jabber client (Gabber) running through a "redir"
session on the 486. Redir is a simple proxy program that
accepts a connection on the "listening" side, and opens a
connection on my behalf from the firewall box. (I do this so
that Gabber doesn't choke when I fire up the VPN software on
my other box. I don't run VPN on the 486 in question.)
-- I often have a remote telnet session into the box open from
work. (Our firewall has a telnet proxy, but not an SSH proxy.
*sigh*)
-- There are a bunch of connections over the loopback interface
that come from Apache. I imagine these are for managing the
child threads:
tcp 0 0 127.0.0.1:1032 127.0.0.1:1033 ESTABLISHED
tcp 0 0 127.0.0.1:1033 127.0.0.1:1032 ESTABLISHED
tcp 0 0 127.0.0.1:1030 127.0.0.1:1031 ESTABLISHED
tcp 0 0 127.0.0.1:1031 127.0.0.1:1030 ESTABLISHED
tcp 0 0 127.0.0.1:1028 127.0.0.1:1029 ESTABLISHED
tcp 0 0 127.0.0.1:1029 127.0.0.1:1028 ESTABLISHED
tcp 0 0 127.0.0.1:1026 127.0.0.1:1027 ESTABLISHED
tcp 0 0 127.0.0.1:1027 127.0.0.1:1026 ESTABLISHED
tcp 0 0 127.0.0.1:1024 127.0.0.1:1025 ESTABLISHED
tcp 0 0 127.0.0.1:1025 127.0.0.1:1024 ESTABLISHED
So the question is, what might be causing the leak? Where should I
look? What information (aside from the above) might be relevant?
I presume this email address goes to a mailing list. Please copy
me directly on any replies, since I don't presently subscribe to any
of the lists.
Thanks in advance for any insight. I'd love to help stomp this bug.
It doesn't affect me horribly (that is, I could live with it easily),
but I'd rather not have to reboot once a month when I could instead
help make Linux perfect. :-)
Regards,
--Joe
--
------------------------------------------------------------------------------
Joseph Zbiciak http://www.primenet.com/~im14u2c/ Not your average "Joe"
R$+@$=W <-- sendmail.cf {$/{{.+ <-- modem noise
!@#!@@! <-- Mr. Dithers swearing Zbiciak <-- Joe's last name
---------------------- Member of the Intellivisionaries ----------------------
|