On Wednesday 02 September 2009 20:44, Cathey, Jim wrote: > We're seeing signs of fd's leaking in BB inetd, when it's > used in the following way. The inetd we're using is the 1.13.2 > version. (I was hooked up with svn, but don't have [and have > never used] git.)
Please try 1.15.0 > The target system is a 300 MHz MIPS-32 (Broadcom > Raven), running 2.6.26.6 Linux, with PREEMPT. Gcc 4.2.3 The > inetd portion of the config is normal, all options are enabled. > (Sorry that I can't include it in this message, the VM through > which my source is accessed has just crashed, hard enough to require > rebooting my PC to get back, and I don't want to lose this > message. I'll follow up with it if it seems important. Gotta > love Windows PC's!) > > The target has this for /etc/inetd.conf: > > # To re-read this file after changes, just do a 'killall -HUP inetd' > > telnet stream tcp nowait.12 root /usr/sbin/telnetd > telnetd -i > > Just the one service, which is commented-out (#) when telnet is > feature-disabled on the target. Note the 12/second rate limit option. > This is an important DoS prevention measure for the target. > > On the development system the following script exists: > > #!/bin/sh > # Bury the target in telnets > > for i in 1 2 3 4 5 6 7 8 9 10; do > for j in 1 2 3 4 5 6 7 8 9 10; do > telnet 172.16.172.2 >/dev/null 2>&1 & > done > done > wait > > which is invoked for this test with: > > while :; do ./bury; done > > On the target via the console, the following runs > (spread out in time, and trimmed to remove extraneous > information) show what is happening: > > # #Before tests starts: > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > # #Test starts now... > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > /proc/934/fd/7 -> socket:[1597] > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > /proc/934/fd/7 -> socket:[1597] > /proc/934/fd/8 -> socket:[1692] > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > /proc/934/fd/7 -> socket:[1597] > /proc/934/fd/8 -> socket:[1692] > /proc/934/fd/9 -> socket:[1738] > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > /proc/934/fd/7 -> socket:[1597] > /proc/934/fd/8 -> socket:[1692] > /proc/934/fd/9 -> socket:[1738] > /proc/934/fd/10 -> socket:[1768] > # procdump /proc/`pidof inetd`/fd > /proc/934/fd/0 -> /dev/null > /proc/934/fd/1 -> /dev/null > /proc/934/fd/2 -> /dev/null > /proc/934/fd/5 -> socket:[1455] > /proc/934/fd/6 -> socket:[1511] > /proc/934/fd/7 -> socket:[1597] > /proc/934/fd/8 -> socket:[1692] > /proc/934/fd/9 -> socket:[1738] > /proc/934/fd/10 -> socket:[1768] > /proc/934/fd/11 -> socket:[1796] > # ... Just "ls -l /proc/`pidof inetd`/fd" works for me. I tried to reproduce it but it seems to work. However, you can be onto something since I see occasional segfaults in strace. -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
