Date: Tue, 7 Dec 1999 10:05:28 -0500 (EST) From: tstromberg@rtci.com To: freebsd-audit@freebsd.org Subject: FreeBSD-audit project & zombies galore. Message-ID: <84728396.944579128399.JavaMail.chenresig@karma>
next in thread | raw e-mail | index | archive | help
For the FreeBSD-auditing project I had previously been running the brute-force audit on just 4.0-CURRENT, but unfortunatly, 4.0-CURRENT was unstable enough that I started running it on a -STABLE box as well. Seeing as 3.4-RELEASE will be coming out in a few weeks, I also thought it'd be beneficial to see if we can't test & fix a bunch of the minor problems we've found.. I didn't expect "Night of the Living Dead" with 4000 zombie processes on my box. What the brute force tester does is try all sorts of combinations of enviroment, input, and argument overflows, and execs them all with the combinations. Some programs get ~3000 tests, but for instance, /usr/sbin/fixmount got 24771 different tests applied to it because of it's enviroment variables and it's linkage to libc & librpcsvc .. A lot of these programs timeout, and since I have better things to do I have a 2 second timeout to abort the system() that calls them. This created some zombies for me. Over 4000 of them to be exact. (sh) and (pax) were all over the process table. I tried to kill -9 them (hey, it worked in -CURRENT for the dozen or so I got), but the zombies were never reaped. I had to reboot to gain any control of the system again because I couldn't fork() anything to be useful after I had managed to login via console. Right now in perl I've just got an alarm(2) going before a system(@args).. after that I also do a killall on the program just in case it's hanging out in the background (will find a friendlier solution shortly). There must be a better way to do this, I just wonder if I will run into this if I add forking and kill my perl forks.. I already attempt to try to kill off the program after I abort it with a timeout (of course however, if say "blah" times out, but has spawned an sh shell, and I kill blah afterwards, the sh shell remains). I'm going to add some more knobs to the tester to say "abort tests when there are >X processes total running". This should be good for zombies because they dissappear when the perl script is completed. I'll probably also add some resource restrictions in login.conf for my testing account, but this doesn't help me so much when I have to do the Solaris tests. The basic questions I have are I guess: - What can I do to avoid having zombied processes? - What should I do to handle zombies processes correctly when they occur? - Why didn't this happen to me under -CURRENT? Right now some zombie favorites include: sh, pax, fpr, rcp.. I'm just going to monitor for now how many zombies happen, and skip tests on the executables that zombie out on me till I find a better way. BTW: I got permission to release the scripts, once I remove some of the more awful bugs & hacks, I'll go ahead and release it. This should happen over the weekend. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-audit" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84728396.944579128399.JavaMail.chenresig>