[Since this problem seems to be a bug in Majordomo, I am cc'ing
this to majordomo-workers; I'd appreciate being cc'd on any discussion,
since I'm not a Majordomo Worker.]
Thomas Leavitt writes:
>> One of our users, who maintains a relatively large mailing list, has
>> had his subscriber lists truncated by Majordomo at least twice. Needless to
>> say, this is quite distressing.
Indeed. :-( I have just had it happen here for the second time. The
first time it happened was in a very unusual situation where 91
unsubscribe directives for the same list arrived within a few minutes
of each other, and the machine started thrashing and the kernel ran out
of file table slots (!). (I have since rebuilt the kernel.) However,
in this last occurrence I have not been able to trace to anything
unusual. My machine is busy and slow, yes, but this should not cause a
subscription list to disappear! (I am running a security-patched 1.91
under Ultrix 4.3.)
Last December, Bob Torres at Netcom wrote that he had experienced a
similar problem; I did not find record that anyone had responded to him
on this list (majordomo-users).
>> I have been told by another list-owner at Netcom that this has happened
>> to her a number of times as well... from this, I suspect this phenomenon,
>> is likely to occur when the load on the server the list is running
>> on peaks, since Netcom machines are cronically overloaded, and the
>> truncations on our site have occured when we've be dealing with rogue processes
>> spamming the system.
>>
>> We are working on a custom solution to this problem, but I thought
>> I'd raise the issue here, and see if anyone else had experienced it,
>> or has identified the cause (we added a number of error checks after
>> the first occurance, but these seem to have been ignored when the
>> phenomenon repeated itself).
Deborah A Hamilton writes:
> This problem also happened to us after transferring two large and
> one enormous mailing list from InterNIC Information Services to
> our host on Information Directory and Database Services. The
> enormous mailing list (scout-report) got spammed at least 4 times
> in one week. We also took a tremendous performance hit since the
> other two large lists are very active.
>
> I've been working on solutions to this problem and have developed
> the following facilities that appear to working somewhat okay:
>
> 1.) Queue all mail coming in to majordomo and the mailing lists
> and process the queue in order to single thread all requests.
> This was a hack on the queuer we have for our email server
> applications. Instead of sending the mail directly to majordomo
> or to resend, it's saved in a queue file with a flag telling
> which service it should be forwarded to. Every half-hour, cron
> kicks off the job to process the queue in order, waiting until
> requested service completes before sending off the next request.
>
> 2.) For large mailing lists (> 2500 subscribers), batch the
> subscription requests and process them as a group once/day.
> This involved a new parameter in the list config files
> (batch_subs = yes|no). If turned on, the subscribe/unsubscribe
> requests are saved in <listname>.sub. Notification is sent
> to the requester that the request has been queued. Once a day,
> cron kicks off a job to process a list's .sub file. The
> requesters are notified when the subscribe/unsubscribe completes,
> and the list-owner gets a list of the subscribed/unsubscribed
> ids.
>
> Since I've implemented these two facilities, the lists have not
> been spammed.
Do you have any idea which of the two measure above has been responsible
for solving the problem, or do you believe the solution to be related
simply to reducing the load on the machine?
> Yes, it slows down getting mail posted to the lists,
> but it has also pretty much eliminated the battles for the lock files
> causing failed majordomo requests and posting email to the lists.
Well, failed requests I can handle; truncated subscription lists are a
very serious problem. Majordomo Workers, do you have any idea what might
be causing this?
Anne. (Administrator for Concordia mail relay and news transfer)
Ms. Anne Bennett, Computing Services, Concordia University, Montreal H3G 1M8
anne@alcor.concordia.ca (514) 848-7606
|
|
