[net.unix-wizards] Runaway Sendmails

pv@uscvax.UUCP (Peter Vanderbilt) (04/08/86)

Several times in the last few weeks, we have had sendmails that create
infinite df* files (in /usr/spool/mqueue) -- the last line is repeated until
space runs out on /usr.

Is there a known bug causing this?  A known fix?

-- 
Peter Vanderbilt
  arpa:  pv@usc-cse.usc.edu
  csnet: pv@usc-cse
  uucp:  uscvax.uucp or
    ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!pv

chris@umcp-cs.UUCP (Chris Torek) (04/12/86)

In article <56@uscvax.UUCP> pv@usc-cse.UUCP (Peter Vanderbilt) writes:
>Several times in the last few weeks, we have had sendmails that create
>infinite df* files (in /usr/spool/mqueue) -- the last line is repeated until
>space runs out on /usr.

I had to fix this once or twice.  There are, as I recall, two loops
in sendmail of the form

	while (!feof(infile)) {
		...
		(void) fgets(buf, sizeof (buf), infile);
		if (ferror(infile))
			[do something about error];
		[append line to data file];
		...
	}

The author obviously expected ferror(infile) to imply feof(infile);
but it does not.  A quick fix is to change the conditions on the
loops to

	while (!feof(infile) && !ferror(infile))

(the loops are in fact `for's, if I recall correctly, so take care
with your search strings; but this is not otherwise important).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu

laubach@hpcea.HP.COM (Mark Laubach) (04/12/86)

We too have had similar problems here with df files filling up the file
system and would be interested in hearing about any fixes.

- Mark Laubach
  R&D Information Resources Group
  Hewlett-Packard Corp.

  UUCP: ...!hplabs!laubach
  ARPA: laubach@hplabs.hp.com  or laubach@hplabs.arpa

hedrick@topaz.RUTGERS.EDU (Charles Hedrick) (04/13/86)

We have also seen runaway sendmails.  At least one cause is improper
error checking in the module collect.c.  Here are the things we have
found so far.  They may be other problems like these, though.

31a32
> 	extern char *RealHostName;  /* 2 host name in err msg */
76,77c77,80
< 	for (; !feof(InChannel); !feof(InChannel) && !ferror(InChannel) &&
< 				 sfgets(buf, MAXFIELD, InChannel) != NULL)
---
> /* 3 add ferror to termination condition to prevent infinite loop on error */
> 	for (; !feof(InChannel) && !ferror(InChannel);
> 	       !feof(InChannel) && !ferror(InChannel) &&
> 			 sfgets(buf, MAXFIELD, InChannel) != NULL)
85c88,90
< 			while ((c = getc(InChannel)) != '\n')
---
> /* 12 avoid infinite loop if error while in loop */
> 			while (((c = getc(InChannel)) != '\n') &&
> 			       (c != EOF))
135,136c140,143
< 	for (; !feof(InChannel); !feof(InChannel) && !ferror(InChannel) &&
< 				 sfgets(buf, sizeof buf, InChannel) != NULL)
---
> /* 3 add ferror to termination condition to prevent infinite loop on error */
> 	for (; !feof(InChannel) && !ferror(InChannel);
> 	       !feof(InChannel) && !ferror(InChannel) &&
> 	         sfgets(buf, sizeof buf, InChannel) != NULL)
165a173
> /* 2 add RealHostName to error message to help us track down problems */
167c175,179
< 		syserr("collect: unexpected close");
---
> 		syserr("collect: %s unexpected close",RealHostName);
> /* 3 add test for error and syserr if found - part of loop prevention */
> 	/* An error is always a bad sign */
> 	if (ferror(InChannel))
> 		syserr("collect: %s input error",RealHostName);