new users added to custom MemberAdaptor don't get emails

Hi folks, I have a setup where lists are not open to be joined by anyone but are managed by an LDAP database. The database is queried once an hour and the members of each list are written to a file which is then read in whenever anything is posted to a list.
My problem is that newly added members seem not to be recognized until I reboot the server. The strange part is that executing /usr/lib/mailman/bin/list_members gives the correct entries including any newly added members while no actual mails are sent to the new members (they don't receive the mails and there are no entries in /var/log/mail.log) until I reboot the server.
I am guessing that the ldap part should be correct since list_members shows the correct entries. I am attaching the files /usr/lib/mailman/Mailman/FileMemberships.py and /var/lib/mailman/lists/testlist/extend.py, which should contain all the relevant information. If anyone is also interested in the part that polls the LDAP server, the whole code can be found at http://ldapsync.sourceforge.net/
Any help is appreciated. Regards, Viktor

On 05/02/2014 08:07 AM, Viktor Dick wrote:
When you run list_members, it runs as a new, separate process so it gets the current version of the members from a new instance of the MemberAdaptor.
However, Mailman's qrunner processes are persistent and they don't 'reload' unless Mailman is restarted. Apparently, once your MemberAdaptor thinks it has the membership list, it doesn't try to update it.
Note that rebooting is overkill. Just restarting Mailman should suffice.
I can't say more about what to do without actually seeing your MemberAdaptor, however you might look at <https://bugs.launchpad.net/mailman/+bug/558106> for an alternative.
The list's content filtering removes non text/plain attachments. They will come through if you ensure they have a MIME Content-Type: of text/plain. Maybe naming them FileMemberships.py.txt and extend.py.txt will convince your mail client to do that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:
OK, I took a quick look at your stuff from <http://sourceforge.net/projects/ldapsync/files/>.
I think your issue is you rely on extend.py to instantiate FileMemberships and reload the member data when the list is instantiated.
I suspect your Mailman is 2.1.14 or older which maintains a list cache in the qrunners so the list gets instantiated and cached and further references to the list object retrieve it from the cache and update it as needed, but it is never again actually instantiated so extend.py is never called again.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2014-05-03 23:55, Mark Sapiro wrote:
That was actually my starting point to develop my MemberAdapter. I did not use it directly because the LDAP server might be down sometimes and I still wanted mails to be delivered. I did not want to try LDAP replication, partly because it seems complicated and partly because I do not want the LDAP database on the webserver (even if the login passwords are hashed).
You are right, it is mailman 2.1.13-5, I am running a debian server. After upgrading to debian wheezy with mailman 2.1.15-1, the problem seems fixed.
Thanks.
regards, Viktor
P.S: It is not wise to register to a mailing list using the address of another mailing list. I actually replied a few days ago, but I used 'reply to all' and that only send an e-mail to myself and the other administrator.

On 05/07/2014 07:15 AM, Viktor wrote:
Good.
It should be OK. Whatever reply issue you had must have been due to some idiosyncrasy in your MUA (Mail client).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 05/02/2014 08:07 AM, Viktor Dick wrote:
When you run list_members, it runs as a new, separate process so it gets the current version of the members from a new instance of the MemberAdaptor.
However, Mailman's qrunner processes are persistent and they don't 'reload' unless Mailman is restarted. Apparently, once your MemberAdaptor thinks it has the membership list, it doesn't try to update it.
Note that rebooting is overkill. Just restarting Mailman should suffice.
I can't say more about what to do without actually seeing your MemberAdaptor, however you might look at <https://bugs.launchpad.net/mailman/+bug/558106> for an alternative.
The list's content filtering removes non text/plain attachments. They will come through if you ensure they have a MIME Content-Type: of text/plain. Maybe naming them FileMemberships.py.txt and extend.py.txt will convince your mail client to do that.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

Mark Sapiro wrote:
OK, I took a quick look at your stuff from <http://sourceforge.net/projects/ldapsync/files/>.
I think your issue is you rely on extend.py to instantiate FileMemberships and reload the member data when the list is instantiated.
I suspect your Mailman is 2.1.14 or older which maintains a list cache in the qrunners so the list gets instantiated and cached and further references to the list object retrieve it from the cache and update it as needed, but it is never again actually instantiated so extend.py is never called again.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2014-05-03 23:55, Mark Sapiro wrote:
That was actually my starting point to develop my MemberAdapter. I did not use it directly because the LDAP server might be down sometimes and I still wanted mails to be delivered. I did not want to try LDAP replication, partly because it seems complicated and partly because I do not want the LDAP database on the webserver (even if the login passwords are hashed).
You are right, it is mailman 2.1.13-5, I am running a debian server. After upgrading to debian wheezy with mailman 2.1.15-1, the problem seems fixed.
Thanks.
regards, Viktor
P.S: It is not wise to register to a mailing list using the address of another mailing list. I actually replied a few days ago, but I used 'reply to all' and that only send an e-mail to myself and the other administrator.

On 05/07/2014 07:15 AM, Viktor wrote:
Good.
It should be OK. Whatever reply issue you had must have been due to some idiosyncrasy in your MUA (Mail client).
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (3)
-
Mark Sapiro
-
Viktor
-
Viktor Dick