[836] in Release_7.7_team

home help back first fref pref prev next nref lref last post

Re: What ho mailq bug?

daemon@ATHENA.MIT.EDU (Jonathon Weiss)
Wed Jan 22 22:14:07 1997

From: Jonathon Weiss <jweiss@MIT.EDU>
To: Carla Fermann <carla@MIT.EDU>
Cc: Bill Cattey <wdc@MIT.EDU>, release-team@MIT.EDU
In-Reply-To: Your message of "Wed, 22 Jan 1997 17:43:12 EST."
             <9701222243.AA09911@mickey-mouse.MIT.EDU> 
Date: Wed, 22 Jan 1997 22:14:00 EST


I talked with Greg about this a little, and we agree that it would be
nice if we could do something about the problem besides publicize it.

It is my belief that going to a sendmail8 based version of sendmail
will solve this problem and that Solaris 2.5.1 uses such a version.
Therefore it is likely that this bug will be fixed in 8.1 anyway.
Assuming that this is correct, we have several options for what to do
between now and then:

	1) ignore the problem
	2) fix the problem
	3) install a kluge

1 doesn't require much discussion.

2 would be nice, but may be excessively difficult.  I seem to recall
that we tried to apply a patch to 2.4 to use a sendmail 8 based
version of sendmail before 8.0 went out and miki had to back it out
for some reason.  If it is just that it needs a tweak or two in the
sendmail.cf I could supply those, but then we get into the issues of
having to force replace teh cf file on all workstations.

3 is pretty easy, but not a perfect solution.  I believe that the
following cron job will remove any bogus lockfiles once they are one
day old.  This means that mail that trips the bug here will be delayed
for about a day, but not for weeks.  Not great, but a lot better than
now.

35 * * * *	/etc/athena/desync; /usr/bin/find /usr/spool/mqueue -name "lf*" -links 1 -mtime +0 -exec /bin/rm -f {} \;


The third option is about a 75% fix for almost no effort.  What do
people think?

	Jonathon


home help back first fref pref prev next nref lref last post