Hi

Does the list owner get a notification if "Send notifications about new registrations to the list owner?" is Yes?

No, just the new added user get an email with the subject: /"Welcome to the "blabla" mailing list"./ Just if I set it to "No" the owner gets the mail with: "blabla@pascalchristen.ch has been successfully subscribed to blabla. (admin mass sub)" //

Are users able to subscribe by other methods, e.g, from the listinfo page or by email? Yes no problem when subscribing from the listinfo. What's in Mailman's 'error' log? Nothing...

Have you tried running Mailman's bin/check_perms? Yes without problems...

Had some similar Problem where an sync_members Script was running as a crown job ... eliminating all new members every Minute ... Hmm nothing special there...and no special qrunner:

/usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=ArchRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=BounceRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=CommandRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=IncomingRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=NewsRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=OutgoingRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=VirginRunner:0:1 -s /usr/local/bin/python2.7 /usr/local/mailman/bin/qrunner --runner=RetryRunner:0:1 -s

Greetings Pascal

Hi

What's in Mailman's subscribe log? Is there an unsubscription? Nothing special. It just contains that the user got added my mass sub, nothing more. See my first mail on that topic where I pasted some log details

The only other thing I can think of is some exception is thrown causing the updated list to not be saved, but that should be logged in the error log. What's in Mailman's bounce log? This should not happen, but possibly the notice to the owner is bouncing and this is causing the unsubscription?

Sadly there's nothing in these logs which match that time I subscribed the user. Will post all the logs I get when adding on Monday

Greeting Pascal

Yes, on the GUI it got added successfully and even in the log it appears:

/logs/subscribe:Sep 20 10:04:59 2018 (20772) ugh_panteghini.ch: new />/shouldfail at pascalchristen.ch <https://mail.python.org/mailman/listinfo/mailman-users>, admin mass sub/

Hi

When you upgraded, is it possible the older instance is still at least partially there in a different path. You could be right. I got a bit deeper into this problem and I discovered something: When I add an user with the mass subscription in the GUI I see that the "testtest_pesc.xyz/config.pck" gets written with the new user but half a second later it gets overwritten with the old one. But at the moment I don't know why.

Our setup: 1 Mailman backend-Server (with all the qrunners - NFS mount of /usr/local/mailman), 2 Webservers (NFS mount of /usr/local/mailman). So all the systems are mounting the same Mailman data.

Do you have any ideas why this happens?

Greetings Pascal

Hi

We still haven't solved that issue.

Is it possible to downgrade from 2.1.29 to 2.1.27 to give it a try?

Greetings Pascal

On 25.09.18 16:44, Mark Sapiro wrote:

On 9/25/18 12:55 AM, Pascal Christen wrote:

...

I got a bit deeper into this problem and I discovered something: When I add an user with the mass subscription in the GUI I see that the "testtest_pesc.xyz/config.pck" gets written with the new user but half a second later it gets overwritten with the old one. But at the moment I don't know why.

Our setup: 1 Mailman backend-Server (with all the qrunners - NFS mount of /usr/local/mailman), 2 Webservers (NFS mount of /usr/local/mailman). So all the systems are mounting the same Mailman data.

I think the scenario maybe something like this:

You submit the mass subscribe. This is forwarded to one of the web servers which locks the list and and does the subscribe, updating the config.pck. Meanwhile, something gets forwarded to another web server which somehow manages to lock the list before it's updated and then save the 'old' config.pck.

Locking is supposed to prevent this and is supposed to be NFS safe, but possibly there is an issue here. See Mailman/LockFile.py.

I suggest careful examination of the web server logs and configs and maybe also MTA logs and configs to see more about what's going on and in what order things are happening.

I'm not familiar with NFS and what it logs, but it's logging may also be useful if detailed enough.

Hi

On 08.02.19 16:02, Mark Sapiro wrote:

You will find tarballs for all released versions at <https://ftp.gnu.org/gnu/mailman/>.

If you installed 2.1.29 from source, just download the version you want, unpack it, configure it with the same command you used for 2.1.29, and install it.

If you installed 2.1.29 from a package, it depends on the package.

Ok I just downgraded and it was much better. Did a patch from 2.1.27 to 2.1.29 had impact on the performance? Because the performance of 2.1.27 is much better compared to 2.1.29 and that's mayeb the reason the users don't get added because of slow performance and locking issue.

With 2.1.27 I had 2 of 100 Users that were not added. Witch 2.1.29 I have ~30 of 100.

Greetings Pascal

On 2/14/19 7:13 AM, Pascal Christen wrote:

Ok I got it. I've just reviewed the patch (https://launchpadlibrarian.net/379908276/patch.txt) for CVE-2018-13796 and found that line:

•        longest = max([len(x) for x in list_names()])

So at every request it gets ALL lists and saves the length of the longest list into "longest". This works well if you have 1 list, but what if you have about 10'000? Not very well guys :D

Currently I have no smart idea how to rewrite the patch. Can you think of something?

Thank you for your analysis. I will try to come up with something better than the current patch. I suspect that part of the issue is with a large number of lists, Mailman's lists/ directory itself occupies several file system blocks and the list_names() function, which the patch calls twice, takes a long time, both in listing the names in the lists/ directory and then checking each name for a subordinate config.pck file.

We can cut that in half by replacing

    # Get the longest listname or 20 if none.
    if list_names():
        longest = max([len(x) for x in list_names()])
    else:
        longest = 20

with

    # Get the longest listname or 20 if none.
    l_names = list_names()
    if l_names:
        longest = max([len(x) for x in l_names])
    else:
        longest = 20

That may help.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan