Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!ukma!nrl-cmf!ames!elroy!cit-vax!ucla-cs!zen!ucbvax!FLEETWOOD.CC.UMICH.EDU!paul
From: paul@FLEETWOOD.CC.UMICH.EDU ('da Kingfish)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo TCP/IP problems
Message-ID: <8711241740.AA05468@fleetwood.cc.umich.edu>
Date: Tue, 24-Nov-87 11:40:56 EST
Article-I.D.: fleetwoo.8711241740.AA05468
Posted: Tue Nov 24 11:40:56 1987
Date-Received: Sat, 28-Nov-87 04:07:48 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 22


if you have /com/sh dumping and filling up your proc_dump file, your
culprit could be syslog.  sendmail is evidently using it when it fires every
hour.

syslog can fill up your disk in one of two ways:

it will go nuts and log its own select I/O errors, or a fork will fail,
and that will show up as a /com/sh something about process
creation/pgm_$invoke or something like that in proc_dump.

To see if this is it, write a small program that logs something over
and over, start it (make sure the syslog daemon is going) and then kill
tcp_server.  (killing tcp_server, ah, simulates whatever problem starts
this off in the first place.)

I am running the 4.3 syslog, which I got going by yanking out the
AF_UNIX, /dev/log, /dev/klog, and /dev/console logging, and using a udp
socket instead of the unix socket for syslog to use in communicating
with syslogd.

--paul