Hi all,
a few days ago I made a mistake (?) of uploading a list of ~7000 addresses into the "bulk subscribe" box. None of them made it into the subscriber list, but at least some of the welcome e-mails went out.
Question: what is mailman actually doing? Is it waiting for all the retries and bounces before it updates the subscriber list? Or has it failed and I need to re-do the whole thing?
I see some of those addresses in the logs so it looks like it's the former. If it is, is there any way to monitor mailman's progress?
(mailman 2.1.12 on centos 6.9)
Thanks in advance,
Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
Question: what is mailman actually doing? Is it waiting for all the retries and bounces before it updates the subscriber list? Or has it failed and I need to re-do the whole thing?
Look in /usr/local/mailman/logs/* /var/spool/mqueue/ or whatever your local equivalent paths are
Julian
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU.
On 09/30/2017 11:47 AM, Julian H. Stacey wrote:
Question: what is mailman actually doing?g?
Look in /usr/local/mailman/logs/* /var/spool/mqueue/ or whatever your local equivalent paths are
It's /var/log/mailman/subscribe in this case, thank you, but it shows "new mail@addr, admin mass sub" for addrs from a to j up to Sep 25. (I sorted the list before upload and it goes all the way to z.) Postfix log shows welcome e-mails still going out as of an hour ago.
So it looks like mailman updates its logs only a little more often then it updates its configs.
Going through postfix log trying to spot an address that looks like it may be from the list is rather inconvenient.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/01/2017 02:34 PM, Dimitri Maziuk wrote:
It's /var/log/mailman/subscribe in this case, thank you, but it shows "new mail@addr, admin mass sub" for addrs from a to j up to Sep 25. (I sorted the list before upload and, but those subscribes were lost it goes all the way to z.) Postfix log shows welcome e-mails still going out as of an hour ago.
So it looks like mailman updates its logs only a little more often then it updates its configs.
The log entries were written as Mailman did the subscribes and sent the welcomes, but those subscriptions were lost when the process aborted before finishing. No more subscriptions are currently being done.
If welcome messages are still going out, they are queued either in Postfix or in Mailman's 'virgin' or 'out' queues, but new subscriptions are not happening since the list membership is still empty.
The queue directories may be in /var/lib/mailman/qfiles/ or /var/spool/mailman/ or somewhere else depending on what mailman package you have.
If you find a bunch of queued welcome messages in one of those queues, you can just remove them. You can view them with Mailman's bin/show_qfiles. You can also stop mailman and if the messages are queued in Mailman, Mailman will stop sending them.
The real question is if your installation is so broken that it takes 5 days to send fewer than half of 7000 welcome messages, what's going to happen when you send a post to a list with 7000 members?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/01/2017 04:55 PM, Mark Sapiro wrote:
The log entries were written as Mailman did the subscribes and sent the welcomes, but those subscriptions were lost when the process aborted before finishing. No more subscriptions are currently being done.
So I don't get it, are you saying that is *was* aborted after the CGI timed out?
Or are you following on my "if something happens to interrupt it"? -- it was a hypothetical question about checkpointing and keeping state during long long-running tasks.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On October 1, 2017 3:34:29 PM PDT, Dimitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:
On 10/01/2017 04:55 PM, Mark Sapiro wrote:
The log entries were written as Mailman did the subscribes and sent the welcomes, but those subscriptions were lost when the process aborted before finishing. No more subscriptions are currently being done.
So I don't get it, are you saying that is *was* aborted after the CGI timed out?
Yes.
Or are you following on my "if something happens to interrupt it"? --
As I see it that's the same thing. The something that happened was the abort of the CGI.
it was a hypothetical question about checkpointing and keeping state during long long-running tasks.
Mailman 2.1 does no check pointing. There is no database in the usual sense. It does have a mechanism for backing up and recovering if delivery of a list message is interrupted, but that's it.
-- Mark Sapiro <mark@msapiro.net> Sent from my Not_an_iThing with standards compliant, open source software.
On 2017-10-01 17:50, Mark Sapiro wrote:
On October 1, 2017 3:34:29 PM PDT, Dimitri Maziuk <dmaziuk@bmrb.wisc.edu> wrote:
So I don't get it, are you saying that is *was* aborted after the CGI timed out?
Yes.
OK, thanks. Now I get to draft 3,500 apologies and then resubscribe everyone except the couple of people who replied with "please stop".
PS there is nothing except postfix, spamd, mailman, and apache serving mailman's interface running on this server. It' running at load avg of 0.0 on 24 cores in 128GB of RAM. AFAICT the only reason for the software to croak on the list that size is its own coding.
Dima
On 10/02/2017 07:58 AM, Dimitri Maziuk wrote:
OK, thanks. Now I get to draft 3,500 apologies and then resubscribe everyone except the couple of people who replied with "please stop".
If you use Mailman's mass subscribe (with smaller chunks, say 1000) you can add the apology to the new welcome message.
PS there is nothing except postfix, spamd, mailman, and apache serving mailman's interface running on this server. It' running at load avg of 0.0 on 24 cores in 128GB of RAM. AFAICT the only reason for the software to croak on the list that size is its own coding.
You need to look in Mailman's 'smtp' log to see how much time is being taken to deliver to postfix. One big killer in delivery from Mailman to Postfix is recipient address validation at smtpd time. I.e., you don't want reject_unknown_recipient_domain in smtpd_recipient_restrictions. Also, you don't need spamd scanning of Mailman's outbound mail as list posts will have been scanned on input.
Whatever the reason, you won't be able to run a viable list if it takes days to deliver 3500 messages. Even an hour would be excessive.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/02/2017 01:10 PM, Mark Sapiro wrote:
You need to look in Mailman's 'smtp' log to see how much time is being taken to deliver to postfix.
Close to .1 s, with an occasional .12 on the date in question.
One big killer in delivery from Mailman to Postfix is recipient address validation at smtpd time. I.e., you don't want reject_unknown_recipient_domain in smtpd_recipient_restrictions.
:) Well I do actually, this being our mail gateway, but I get the point. The more reason to outsource this to out university's IT instead of running it locally.
Also, you don't need spamd scanning of Mailman's outbound mail as list posts will have been scanned on input.
Whatever the reason, you won't be able to run a viable list if it takes days to deliver 3500 messages. Even an hour would be excessive.
Of course it's not scanning outbound mail, but it is scanning the incoming on delivery, using up cycles and i/o.
/var/log/mailman/smtp is interesting, actually:
Sep 25 15:53:57 2017 (7782) <mailman.0.1506372716.29657.XXX@XXX> smtp to XXX for 1 recips, completed in 0.081 seconds ... Sep 25 15:59:06 2017 (7782) <mailman.2.1506373144.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.061 seconds Sep 25 16:48:39 2017 (7782) <mailman.2.1506376117.7779.XXX@XXX> smtp to XXX for 1 recips, completed in 0.065 seconds Sep 25 19:03:16 2017 (7782) <mailman.3.1506384195.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.079 seconds Sep 25 19:33:19 2017 (7782) <mailman.4.1506385998.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.069 seconds Sep 26 01:14:46 2017 (7782) <mailman.0.1506406484.11544.XXX@XXX> smtp to XXX for 1 recips, completed in 0.062 seconds Sep 26 12:12:45 2017 (7782) <mailman.3.1506445964.7779.XXX@XXX> smtp to XXX for 1 recips, completed in 0.060 seconds
There's 3200 of these lines total, so at .1s/address it should've ran in 320 seconds. Instead it ran for 6 minutes, then hours later a message or two for a while, and nothing after Sep 26 12:12:45.
/var/log/mailman/subscribe goes
Sep 25 15:51:56 2017 (29657) XXX: new aaa@ADDR, admin mass sub
to
Sep 25 15:53:56 2017 (29657) XXX: new jjj@ADDR, admin mass sub
and ends there. To my uneducated eye it looks like smtp transactions haven't even started until the subscription's gone about halfway through and presumably aborted.
Anyway, this is getting academic. What I wanted to know was is it dead or is it still doing something behind the scenes, and I got the answer.
Thanks everyone.
Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/02/2017 12:22 PM, Dimitri Maziuk wrote:
One big killer in delivery from Mailman to Postfix is recipient address validation at smtpd time. I.e., you don't want reject_unknown_recipient_domain in smtpd_recipient_restrictions.
:) Well I do actually, this being our mail gateway, but I get the point. The more reason to outsource this to out university's IT instead of running it locally.
This is easily worked around. Define another "smtpd" service in master.cf on an alternate port with an override for smtpd_recipient_restrictions and use that port for Mailman delivery, but that may not be needed anyway. See below.
/var/log/mailman/smtp is interesting, actually:
Sep 25 15:53:57 2017 (7782) <mailman.0.1506372716.29657.XXX@XXX> smtp to XXX for 1 recips, completed in 0.081 seconds ... Sep 25 15:59:06 2017 (7782) <mailman.2.1506373144.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.061 seconds
OK. So the bulk of the mail was delivered to Postfix in a bit over 5 minutes. That seem quite reasonable. I clearly misunderstood what you ment when you said mail was still going out after days.
Sep 25 16:48:39 2017 (7782) <mailman.2.1506376117.7779.XXX@XXX> smtp to XXX for 1 recips, completed in 0.065 seconds Sep 25 19:03:16 2017 (7782) <mailman.3.1506384195.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.079 seconds Sep 25 19:33:19 2017 (7782) <mailman.4.1506385998.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.069 seconds Sep 26 01:14:46 2017 (7782) <mailman.0.1506406484.11544.XXX@XXX> smtp to XXX for 1 recips, completed in 0.062 seconds Sep 26 12:12:45 2017 (7782) <mailman.3.1506445964.7779.XXX@XXX> smtp to XXX for 1 recips, completed in 0.060 seconds
Some of these may be retries of temp fails from Postfix (anything in smtp-failure?) and some may be unrelated.
There's 3200 of these lines total, so at .1s/address it should've ran in 320 seconds. Instead it ran for 6 minutes,
Actually 5 minutes and 9 seconds or 309 seconds by the logs above.
then hours later a message or two for a while, and nothing after Sep 26 12:12:45.
/var/log/mailman/subscribe goes
Sep 25 15:51:56 2017 (29657) XXX: new aaa@ADDR, admin mass sub
to
Sep 25 15:53:56 2017 (29657) XXX: new jjj@ADDR, admin mass sub
and ends there. To my uneducated eye it looks like smtp transactions haven't even started until the subscription's gone about halfway through and presumably aborted.
The welcome message is queued in Mailman's virgin queue and processed asynchronously by VirginRunner which moves it to Mailman's out queue where it is processes (again asynchronously by OutgoingRunner).
Anyway, this is getting academic. What I wanted to know was is it dead or is it still doing something behind the scenes, and I got the answer.
Yes, it is 'academic' but a deeper understanding of the processes involved can't hurt. I'm compulsive (often too much so) about answering every outstanding question, even if they are only my own questions.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/02/2017 02:50 PM, Mark Sapiro wrote:
On 10/02/2017 12:22 PM, Dimitri Maziuk wrote: ...
Sep 25 15:53:57 2017 (7782) <mailman.0.1506372716.29657.XXX@XXX> smtp to XXX for 1 recips, completed in 0.081 seconds ... Sep 25 15:59:06 2017 (7782) <mailman.2.1506373144.7778.XXX@XXX> smtp to XXX for 1 recips, completed in 0.061 seconds
OK. So the bulk of the mail was delivered to Postfix in a bit over 5 minutes. That seem quite reasonable. I clearly misunderstood what you ment when you said mail was still going out after days.
Mea culpa, but that's why I had to ask here. Before you guys clued me in on which mailman logs meant what, my best bet was looking at postfix log. In there, however, you would see the messages deferred and being retried by postfix. There's message to at least one of these addresses still being retried (or was, back when I said "mail's still going out"), but I couldn't tell when it came out of mailman without much backtracking.
Some of these may be retries of temp fails from Postfix (anything in smtp-failure?) and some may be unrelated.
One failure logged in that time, to one of these addresses, and that's only an invalid address that got past the regexp I used to clean up the list.
Yes, it is 'academic' but a deeper understanding of the processes involved can't hurt. I'm compulsive (often too much so) about answering every outstanding question, even if they are only my own questions.
:) I find I often don't wanna know.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/2/2017 7:58 AM, Dimitri Maziuk wrote:
PS there is nothing except postfix, spamd, mailman, and apache serving mailman's interface running on this server. It' running at load avg of 0.0 on 24 cores in 128GB of RAM. AFAICT the only reason for the software to croak on the list that size is its own coding.
While mailman routinely handles much larger lists (1), you seem to be very concerned about the size of a HTTP-based bulk add operation when there are other methods of adding that many recipients. Perhaps mailman does have a bug in the area, but there are many other potential factors that could slow things down or stop them completely (2).
It also sounds like there are other issues with the system, like postfix delivery times and the length of the CGI timeout.
If you're receiving "please stop" messages from users, maybe those users don't want to be on this list at all.
This all seems like making a mountain out of a molehill. If you've been satisfied with mailman, why not continue to be satisfied in all other areas and just not to large bulk adds via http? (My car is a great car but won't carry 500kg of cargo, so I don't ask it to.)
Later,
z!
(1) https://wiki.list.org/DOC/What%20is%20the%20largest%20list%20Mailman%20can%2...)
(2) is the mailman installed on local disk or an NFS share? what the locking scheme? timeouts? etc
On 10/02/2017 01:16 PM, Carl Zwanzig wrote:
(My car is a great car but won't carry 500kg of cargo, so I don't ask it to.)
Well I bet your car comes with a manual that says what its max cargo capacity is. Could you point me at The Fine Manual for mailman where it says how many addresses I can subscribe through the web interface?
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/2/2017 12:37 PM, Dimitri Maziuk wrote:
Could you point me at The Fine Manual for mailman where it says how many addresses I can subscribe through the web interface?
I can't (and as Mark mentioned, it's installation-dependent), but it would be helpful to others if you would add something to the wiki with your experiences and relevant config.
z!
On 09/29/2017 11:34 AM, Dimitri Maziuk wrote:
a few days ago I made a mistake (?) of uploading a list of ~7000 addresses into the "bulk subscribe" box. None of them made it into the subscriber list, but at least some of the welcome e-mails went out.
Question: what is mailman actually doing? Is it waiting for all the retries and bounces before it updates the subscriber list? Or has it failed and I need to re-do the whole thing?
Presumably the web browser timed out or was interrupted. The process is subscribing the members one at a time. This will send a welcome as each user is subscribed, but the updated list configuration is not saved until the process is complete. Thus, if it's interrupted prior to completion, the list is not actually updated and no one is subscribed.
I see some of those addresses in the logs so it looks like it's the former. If it is, is there any way to monitor mailman's progress?
It's done. Nothing is "in progress". You might look at the web server logs for the actual POST entry. It probably shows a 500 status and there may be an error message with traceback in the web server's error log and/or Mailman's error log.
If you really wanted to add those members, you need to rerun the mass subscribe, preferably in smaller chunks, or you could use Mailman's command-line bin/add_members. If you use the web UI, you can add "additional text" to the welcome message to the effect that the user should ignore a prior welcome if any. This is not available with add_members.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 2017-09-30 13:15, Mark Sapiro wrote:
The process is subscribing the members one at a time. This will send a welcome as each user is subscribed, but the updated list configuration is not saved until the process is complete. Thus, if it's interrupted prior to completion, the list is not actually updated and no one is subscribed.
But the welcome messages have been sent so interrupting it and re-running with smaller address chunks will have some people receive the welcome message twice. I'd like to avoid that.
It's done. Nothing is "in progress".
I am not asking about the web interface. I am assuming that bin/add_members will also "subscribe the members one at a time" and my definition of "in progress" is they are not all subscribed yet. AFAICT nothing is done until they are -- this is the point. If mailman was updating the membership list one subscriber at a time, I wouldn't have asked. BTW bin/list_members isn't showing anything as "done" yet, by my definition of "done", either.
That said, the part about subscribing them one at a time but not updating list configuration until all is done is what I wanted to confirm, thank you.
I assume it does save state internally and the process will be resumed if interrupted? (E.g. disk crash, power loss, PFY decides to update the kernel and reboot because they didn't get the memo?)
Thanks again, Dima
Hello Dimitri Maziuk. On Sat, 30 Sep 2017 16:31:23 -0500, you wrote:
But the welcome messages have been sent so interrupting it and re-running with smaller address chunks will have some people receive the welcome message twice. I'd like to avoid that.
I don't think so. My My Mailman installation complains that the user already is subscribed if I want to subscribe him/her again. The same happens when I want to unsubscribe a non-existing user.
Christian
Christian F. Buser, Hohle Gasse 6, CH-5507 Mellingen (Switzerland)
Hilfe fuer Strassenkinder in Ghana: http://www.chance-for-children.org
.
On 09/30/2017 03:15 PM, Christian F Buser via Mailman-Users wrote:
Hello Dimitri Maziuk. On Sat, 30 Sep 2017 16:31:23 -0500, you wrote:
But the welcome messages have been sent so interrupting it and re-running with smaller address chunks will have some people receive the welcome message twice. I'd like to avoid that.
I don't think so. My My Mailman installation complains that the user already is subscribed if I want to subscribe him/her again. The same happens when I want to unsubscribe a non-existing user.
Except in this case the users aren't subscribed because the process was aborted and configuration changes were lost so mass subscribe will subscribe them and send a welcome if requested.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 09/30/2017 02:31 PM, Dimitri Maziuk wrote:
But the welcome messages have been sent so interrupting it and re-running with smaller address chunks will have some people receive the welcome message twice. I'd like to avoid that.
TRhe welcome messages contain randomly generated user passwords which will be different when the user is actually subscribed.
You could figure from logs which users received welcomes and mass subscribe them without sending a welcome, but then the welcome they received will not have the correct password.
It's done. Nothing is "in progress".
I am not asking about the web interface. I am assuming that bin/add_members will also "subscribe the members one at a time" and my definition of "in progress" is they are not all subscribed yet.
It's in progress as far as you're concerned, but not as far as Mailman is concerned. As far as Mailman is concerned, some users were sent welcome messages, but no one has been subscribed. End of story.
AFAICT nothing is done until they are -- this is the point. If mailman was updating the membership list one subscriber at a time, I wouldn't have asked. BTW bin/list_members isn't showing anything as "done" yet, by my definition of "done", either.
And it won't no matter how long you wait.
That said, the part about subscribing them one at a time but not updating list configuration until all is done is what I wanted to confirm, thank you.
I assume it does save state internally and the process will be resumed if interrupted? (E.g. disk crash, power loss, PFY decides to update the kernel and reboot because they didn't get the memo?)
Wrong. You have to start over. Nothing is saved from the first attempt. The process died and the state was restored to the last known good state which is before anyone was subscribed.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 09/30/2017 05:19 PM, Mark Sapiro wrote:
On 09/30/2017 02:31 PM, Dimitri Maziuk wrote: .. It's in progress as far as you're concerned, but not as far as Mailman is concerned. As far as Mailman is concerned, some users were sent welcome messages, but no one has been subscribed. End of story. ...
I assume it does save state internally and the process will be resumed if interrupted? ... Wrong. You have to start over. Nothing is saved from the first attempt. The process died and the state was restored to the last known good state which is before anyone was subscribed.
So anything goes wrong, everybody got the welcome spam but nobody got subscribed. People who get the welcome messages (up to "j" now) and click on the unsubscribe link get an error. For another week or so, judging by what I can work out from the postfix logs -- because there's no other place to look. I wish I found any of it surprising. Sadly I've been dealing with software (including my own) for too long for that. Situation normal, moving along.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/01/2017 02:44 PM, Dimitri Maziuk wrote:
For another week or so, judging by what I can work out from the postfix logs -- because there's no other place to look.
See my other reply at <https://mail.python.org/pipermail/mailman-users/2017-October/082512.html>
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 9/29/2017 11:34 AM, Dimitri Maziuk wrote:
(mailman 2.1.12 on centos 6.9)
I don't think that Mark mentioned it, but 2.1.12 is -painfully- old (as is centos 6.9) and centos packages often lag way behind the corresponding source versions.
If you need to stick with 6.9, I would consider ditching the centos package and installing the current mailman from source. Otherwise, can you move to a more modern Linux and more recent mailman?
Later,
z!
On 2017-10-01 22:23, Carl Zwanzig wrote:
On 9/29/2017 11:34 AM, Dimitri Maziuk wrote:
(mailman 2.1.12 on centos 6.9)
I don't think that Mark mentioned it, but 2.1.12 is -painfully- old (as is centos 6.9) and centos packages often lag way behind the corresponding source versions.
If you need to stick with 6.9, I would consider ditching the centos package and installing the current mailman from source. Otherwise, can you move to a more modern Linux and more recent mailman?
Mailman's been been trouble- and maintenance-free for us since we switched from whatever-that-perl-thing-was-called all those years ago, and it never occurred to me it'd something as silly as abort the running op because my browser timed out. Now that I know, I'll consider "upgrading" -- to the university-run lyris: I might as well outsource the whole thing.
Dima
Dimitri Maziuk wrote:
On 2017-10-01 22:23, Carl Zwanzig wrote:
On 9/29/2017 11:34 AM, Dimitri Maziuk wrote:
(mailman 2.1.12 on centos 6.9)
I don't think that Mark mentioned it, but 2.1.12 is -painfully- old (as is centos 6.9) and centos packages often lag way behind the corresponding source versions.
If you need to stick with 6.9, I would consider ditching the centos package and installing the current mailman from source. Otherwise, can you move to a more modern Linux and more recent mailman?
Mailman's been been trouble- and maintenance-free for us since we switched from whatever-that-perl-thing-was-called all those years ago, and it never occurred to me it'd something as silly as abort the running op because my browser timed out.
Though the consequences of timeout were unfortunate, & Mailman would benefit from patching, I wouldn't blame Mailman, as you first wrote:
a few days ago I made a mistake (?) of uploading a list of ~7000 addresses into the "bulk subscribe" box.
Just delete the question mark: Yes it Was a silly mistake !
Now that I know, I'll consider "upgrading" -- to the university-run lyris: I might as well outsource the whole thing.
Better adopt the normal procedure for free source projects: Write & submit patches to project, to fix your problem.
Cheers, Julian
Julian H. Stacey, Computer Consultant, BSD Linux Unix Systems Engineer, Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/ UK stole 3,500,000 votes; 700,000 from Brits in EU.
On 10/02/2017 07:47 AM, Dimitri Maziuk wrote:
Mailman's been been trouble- and maintenance-free for us since we switched from whatever-that-perl-thing-was-called all those years ago, and it never occurred to me it'd something as silly as abort the running op because my browser timed out.
"all those years ago" and before, things like "real" databases, checkpointing, recovery and rollback, and adding 7000 users at once to a mailing list were not things we thought much about in a mailing list manager. The fact that Mailman has "been been trouble- and maintenance-free" for you for all those years is a tribute to the fact that we got at least most of it right.
If you want a mailing list manager with a modern design, I'd recommend Mailman 3.
And "abort the running op because my browser timed out" is not Mailman's doing. That's your web server and its CGI interface.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On 10/02/2017 02:19 PM, Mark Sapiro wrote:
And "abort the running op because my browser timed out" is not Mailman's doing. That's your web server and its CGI interface.
Oh, I agree: mailman worked exactly as designed. Whoever designed that particular assumed it'll take zero time to process an uploaded list of an unknown size, and that did precisely what ass-u-me always does. No surprises there, unfortunately.
Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 02-Oct-17 15:35, Dimitri Maziuk wrote:
Oh, I agree: mailman worked exactly as designed. Whoever designed that particular assumed it'll take zero time to process an uploaded list of an unknown size, and that did precisely what ass-u-me always does. No surprises there, unfortunately. No, the requirement was that you'd set the timeout on your webserver to accommodate your environment.
The Mailman folks can't know what that is. As the site administrator, you are expected to.
E.g. for Apache, see the TimeOut directive, which is a balance between preventing denial of service attacks, and letting long operations complete.
But if you want an (apparently) perfect hands-off experience, by all means outsource to your IT department. Then they'll be responsible for the system-level analysis, implementation, and support.
If this is the case, I do not recommend Mailman V3. Although it does have an improved design, it still requires administration. And despite efforts by the developers, it is not yet as close to turnkey operation as Mailman V2.1. I'm sure it will be - eventually. But it has a long way to go. Right now, it is more complex to setup, is missing features, has no translations, and has more bugs.
From your comments on this thread, Mailman V3 will not (yet) meet your expectations.
On 10/02/2017 02:54 PM, tlhackque via Mailman-Users wrote: ...
From your comments on this thread, Mailman V3 will not (yet) meet your expectations.
Mailman 3 doesn't seem to be available from my distro vendor.
-- Dimitri Maziuk Programmer/sysadmin BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu
On 10/02/2017 01:52 PM, Dimitri Maziuk wrote:
On 10/02/2017 02:54 PM, tlhackque via Mailman-Users wrote: ...
From your comments on this thread, Mailman V3 will not (yet) meet your expectations.
Mailman 3 doesn't seem to be available from my distro vendor.
That will change. I know Debian is currently working on packaging Mailman 3, but have no info as to targets or timelines or other vendor's downstream packages.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (6)
-
Carl Zwanzig -
Christian F Buser -
Dimitri Maziuk -
Julian H. Stacey -
Mark Sapiro -
tlhackque