Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!munnari.oz.au!metro!usage.csd.unsw.oz.au!usage.csd!neilb From: neilb@spectrum.cs.unsw.oz.au (Neil Brown) Newsgroups: comp.sys.apollo Subject: Re: tcpd problems Message-ID: Date: 24 May 91 03:07:05 GMT References: Sender: news@usage.csd.unsw.oz.au Distribution: comp Organization: none Lines: 30 In-reply-to: ianb@ocf.Berkeley.EDU's message of 23 May 91 04:33:25 GMT Organisation: School of Computer {Science and Engineering}, The University of New South Wales, Australia We too have had a number of problems with tcpd spinning. It invariably involves the mbufs being all used up, as in: 335/336 mbufs in use: 111/112 ( 80-byte) mbufs used/allocated 112/112 (1560-byte) mbufs used/allocated 112/112 (9216-byte) mbufs used/allocated As David Funk mentioned, this can happen when some process has a socket open but is not processing incoming packets, in which case killing the process should free things up. When it happens here though, the reason that the process isn't processing incoming packets is that it has exited! For some reason this doesn't always close the socket properly, so we have the situation where tcpd thinks packets for some particular port are wanted, but no processes actually wants them. Result: packet buildup and loss of mbufs. Cure: reboot. We have told the Australasian Response Center and they have been looking into the problem. The latest patch tape (May I think) has a new version of tcpd and installing this has reduced the problem significantly, but it hasn't gone away completely. We await further developments. NeilBrown neilb@cs.unsw.oz.au