In message <199504071441.HAA10825@miles.greatcircle.com>,
"Elena Fraboschi" writes:
>(1) I installed the mailing lists in /u5/mail/lists. The lists
> are owned by majordom.majordom, 664 as recommended. Then
> people began to subscribe and unsubscribe, and already
> three times I have been confronted with the nightmarish
> situation in which a list that had 859 subscribers, say,
> gets overwritten with another list, same name of course,
> totalling 0 bytes. In other words, the list gets erased.
> (The three times have been three different lists.)
> I have back-up copies, but surely that's not the answer.
> Does anyone have a guess as to what is going on here?
>
> I know that when subscribers subscribe or unsubscribe,
> a L.<listanme> is created, as well as a <listname>.new.
> The problem then would take place when the lock file
> is removed and <listname>.new becomes <listname>. Help!
1) Make sure you have lots of space on the disk where majordomo will
be doing its list manipulation. It isn't extremely robust in
checking for errors in writing to disk.
2) Try this hack. Find the following code fragment from do_unsubscribe
in the majordomo file.
# we deleted exactly 1 name, so now we shuffle the files
link("$listdir/$clean_list", "$listdir/$clean_list.old") ||
&abort("link(\"$listdir/$clean_list\", \"$listdir/$clean_list.old\"): $!");
unlink("$listdir/$clean_list");
link("$listdir/$clean_list.new", "$listdir/$clean_list") ||
&abort("link(\"$listdir/$clean_list.new\", \"$listdir/$clean_list\"): $!");
unlink("$listdir/$clean_list.old");
print REPLY "Succeeded.\n";
and prepend something like:
# check to see if the size changed too much.
$size_change = (-s "$listdir/$clean_list") -
(-s "$listdir/$clean_list.new");
if ($size_change > 256 ) {
#unlink("$listdir/$clean_list.new");
&abort("size change $listdir_$clean_list");
}
This will leave the new version of the clean list around so you can
look at it to try to debug problems. It should recover more
gracefully, but this will stop the loassage problem in any case. Also
it should keep enough info around to diagnose a possible cause I hope.
You can uncomment the unlink if you want majordomo to try to recover
somewhat from the problem.
-- John
John Rouillard
Senior Systems Administrator IDD Information Services
rouilj@dstar.iddis.com Waltham, MA (617) 890-7227 x337
(617) 487-3937 (Direct)
Senior Systems Consultant (SERL Project) University of Massachusetts at Boston
rouilj@cs.umb.edu (preferred) Boston, MA, (617) 287-6480
===============================================================================
My employers don't acknowledge my existence much less my opinions.
|
|
