russo@chaos.utexas.edu (Thomas Russo) (02/01/90)
What version number of sendmail does SGI ship with its 4D systems and if it is not the latest version (which I believe is 5.6something) are there any plans to ship the latest version with the next release? Near as I can tell, SGIs sendmail is version 5.52. Is this correct? I have recently read in comp.security.announce that the latest version might have fixed some holes. It might be nice to see the new version from SGI. On top of that, we occasionally (say, every 3 or 4 months) get into a state where our sendmail starts spewing forth many many children until the process table fills up. Many moons ago I posted to our local network ops bboard and they told me "try porting sendmail 5.6? to your system. We had that happen with some old versions." I tried to do the port, but it stepped on too many bsdisms. Today I had 60 sendmails running, so I post again: Has anyone else ever found there sendmail forking too many children? If so, have you identified the source? Have you found a cure? Answers to any subset of the questions in the above post would be greatly appreciated. Thomas Russo Center for Nonlinear Dynamics, University of Texas at Austin russo@chaos.utexas.edu or phib421@utchpc.bitnet ------
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (02/02/90)
In article <23981@ut-emx.UUCP>, russo@chaos.utexas.edu (Thomas Russo) writes: > > What version number of sendmail does SGI ship with its 4D systems and > if it is not the latest version (which I believe is 5.6something) are > there any plans to ship the latest version with the next release? > Near as I can tell, SGIs sendmail is version 5.52. Is this correct? 5.52 with debug and test of worm fame turned off. > I have recently read in comp.security.announce that the latest version > might have fixed some holes. It might be nice to see the new version > from SGI. The recent flap concerned an "improvement" made by a solar outfit its recent version. It applies only to their stuff. > On top of that, we occasionally (say, every 3 or 4 months) get into > a state where our sendmail starts spewing forth many many children > until the process table fills up. Many moons ago I posted to our > local network ops bboard and they told me "try porting sendmail 5.6? > to your system. We had that happen with some old versions." I tried > to do the port, but it stepped on too many bsdisms. Today I had 60 > sendmails running, so I post again: Has anyone else ever found there > sendmail forking too many children? If so, have you identified the source? > Have you found a cure? > > Thomas Russo > Center for Nonlinear Dynamics, University of Texas at Austin > russo@chaos.utexas.edu or phib421@utchpc.bitnet Boiling sendmails can happen as a result of many things. The most common cases I have seen result when a remote machine has trouble completing a transaction, and keeps retrying. That can be caused by sendmail.cf bugs on either end. A somewhat less common class of cases results from local sendmail.cf bugs which cause each sendmail to go off the deep end rewriting without expanding forever. A third case can happen if you run `ypserv -i` and your name server and ypserv get to screaming at each other. There is a fix for the last problem in a previous or immediately forthcoming release--I've forgotten which. The sympthom of the first case is helped by changing the notion of "load" that sendmail computes to pay attention to its forks. That change, which requires squashing many extra forks and adding a counter, may already be in IRIX 3.2. These boiling problems apply to all versions of sendmail, including 5.61. Unfortunately, the stuff in sendmail.cf is a program. There is no alternative to debugging it. Vernon Schryver Silicon Graphics vjs@sgi.com