[comp.mail.sendmail] Why do I get hung sendmails?

roy@phri.UUCP (Roy Smith) (10/03/89)

	Under SunOS-3.5.2 using IDA Sendmail 5.59++/IDA-1.2.5, we
occasionally get a bunch of sendmails hung, with consecutive (or nearly so)
pids.  They never seem to use up any cpu time, but they do eat VM and space
in various system tables, so I'd like to figure out how to prevent them.
Anybody have any idea what might be happening?  Here's a current example:

USER       PID %CPU %MEM   SZ  RSS TT STAT  TIME COMMAND
root      2224  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
root      2223  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
root      2222  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
root      2221  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
-- 
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"

barnett@crdgw1.crd.ge.com (Bruce Barnett) (10/11/89)

In article <4026@phri.UUCP>, roy@phri (Roy Smith) writes:
>USER       PID %CPU %MEM   SZ  RSS TT STAT  TIME COMMAND
>root      2224  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
>root      2223  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
>root      2222  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)
>root      2221  0.0  0.0  280    0 ?  IW    0:00 -running queue (sendmail)

I can think of two possible causes for this, Roy.

1) the queue is too short (/usr/lib/sendmail -bd -q15m) vs
	(/usr/lib/sendmail -bd -q1h)
2) The mailer has a -I option in it.
   This was causing problems on machines on our internal; network when
   the ethernet mailer had the -I option.

   What happens is that the internal machine sends to the gateway, which
   then tries to make a connection to the remote machine.
   Until the mail is delivered, the internal machine's sendmail will not
   exit.


I deleted the -I flag, and that seemed to fix the problem.

--
Bruce G. Barnett	<barnett@crd.ge.com>   uunet!crdgw1!barnett