tickets #166466
openopenSUSE KDE mailing list down?
Added by javierllorente 3 months ago. Updated 15 days ago.
0%
Description
Hello everyone!
Unfortunately, it seems that there are some issues with the openSUSE-KDE mailing list (kde@lists.opensuse.org).
Yesterday I sent a message to it and it doesn't appear anywhere (going around in circles in cyberspace?). I am subscribed to the mailing list, I have also checked the Web UI (lists.opensuse.org) and have even sent a message via the Web UI (start new thread); "No discussions this month (yet)" ;-(
Some relevant bits from this morning's chat in the #opensuse-admin IRC channel:
jllorente: I'm not sure, I find it in the postfix on the mailman machine but not inside mailman . but other messages like to factory I do find from you.
I can send (and receive) messages from the Factory mailing list without any issues. Regarding the KDE mailing list, I don't know if it's me or a general issue.
Could you please take a look at it?
Thanks!
Updated by cboltz 3 months ago
It looks like the kde list is indeed broken.
grep -C50 for the Message-ID of both of your mails to the kde list in /var/log/mailman/mailman.log (or its logrotated version) shows that they arrived at mailman, but triggered an exception two seconds later:
Sep 05 16:48:55 2024 (26593) ACCEPT: <26818192.1r3eYUQgxm@probook>
[... some unrelated GET requests removed ...]
Sep 05 16:48:57 2024 (26597) Uncaught runner exception: 'NoneType' object has no attribute 'email'
Sep 05 16:48:57 2024 (26597) Traceback (most recent call last):
File "/usr/lib/python3.11/site-packages/mailman/core/runner.py", line 179, in _one_iteration
self._process_one_file(msg, msgdata)
File "/usr/lib/python3.11/site-packages/mailman/core/runner.py", line 272, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mailman/runners/pipeline.py", line 37, in _dispose
process(mlist, msg, msgdata, pipeline)
File "/usr/lib/python3.11/site-packages/mailman/core/pipelines.py", line 53, in process
handler.process(mlist, msg, msgdata)
File "/usr/lib/python3.11/site-packages/mailman/handlers/member_recipients.py", line 84, in process
recipients = set(member.address.email
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3.11/site-packages/mailman/handlers/member_recipients.py", line 84, in <genexpr>
recipients = set(member.address.email
^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'email'
Sep 05 16:48:57 2024 (26597) SHUNTING: 1725554937.5895562+19965c8ec1924e7b256cd9a2640f6b176292618f
Sep 06 09:00:26 2024 (26593) ACCEPT:
<172561322557.52398.8706903641607628372@mailman3.infra.opensuse.org>
[... some unrelated GET requests removed ...]
[... exactly the same exception ...]
Sep 06 09:00:28 2024 (26597) SHUNTING: 1725613228.2183332+9482ea0dc06f895bf66e1bb10ddd3dacb2fb8df0
So we now at least have an error message ;-)
Unfortunately I don't know what causes this error, or how to fix it.
The code around line 84 is:
recipients = set(member.address.email
for member in mlist.regular_members.members
if member.delivery_status == DeliveryStatus.enabled)
My guess is that one of the subscribers is "broken" somehow. I don't see any obvious problem in the subscriber list in the web interface, so someone will need to check it on the database level (or in worst case add some debugging code to find out which member causes this).
Updated by crameleon 3 months ago
Thanks for the additional details.
The issue can be reproduced when querying the members using the mailman CLI as well:
mailman@mailman3:~> mailman members kde@lists.opensuse.org
Traceback (most recent call last):
< same as in log output >
There don't seem to be any "empty" addresses in the list which could explain this:
mailman=> SELECT address.id,address.email FROM address JOIN member ON address.id = address_id WHERE member.list_id = 'kde.lists.opensuse.org' AND address.email = '';
id | email
----+-------
(0 rows)
Reproducing with mailmanclient
does not help either:
import mailmanclient
from operator import attrgetter
client = mailmanclient.Client("http://0.0.0.0:8001/3.1")
mlist = client.get_list("kde@lists.opensuse.org")
addresses = []
for member in mlist.members:
addresses.append(member.address)
for address in sorted(addresses, key=attrgetter('email')):
print(address)
All addresses are printed.
I tried reconstructing the zope interface which the mailman CLI uses as well, but that turned out to be very complicated.
So I added some debugging to cli_members.py which is not ideal but better than adding to the code behind the server process.
for address in addresses:
if not hasattr(address, 'email'):
print(address)
yields there indeed being one address which is None
.
for member in list(roster.members):
if member.address is None:
print(member)
print(member.user)
print(member.user_id)
yields:
<Member: None on kde@lists.opensuse.org as MemberRole.member>`
<User "DJR" (288462282097074430330836705058388050936) at 0x7fe04109a950>
127136
Taking this back to SQL, it seems there are no entries in the address
table with that user_id
at all.
It seems the user is subscribed to other lists as well: SELECT * FROM member WHERE user_id = 127136;
.
However, members with no address reference seem to be a relatively common occurrence: SELECT * FROM member WHERE address_id IS NULL;
- hence I'm not sure this is the right lead and remain with the question what the issue with this specific user and mailing list is.
Updated by javierllorente 3 months ago
crameleon wrote in #note-3:
Thanks for the additional details.
The issue can be reproduced when querying the members using the mailman CLI as well:
mailman@mailman3:~> mailman members kde@lists.opensuse.org Traceback (most recent call last): < same as in log output >
There don't seem to be any "empty" addresses in the list which could explain this:
mailman=> SELECT address.id,address.email FROM address JOIN member ON address.id = address_id WHERE member.list_id = 'kde.lists.opensuse.org' AND address.email = ''; id | email ----+------- (0 rows)
Reproducing with
mailmanclient
does not help either:import mailmanclient from operator import attrgetter client = mailmanclient.Client("http://0.0.0.0:8001/3.1") mlist = client.get_list("kde@lists.opensuse.org") addresses = [] for member in mlist.members: addresses.append(member.address) for address in sorted(addresses, key=attrgetter('email')): print(address)
All addresses are printed.
I tried reconstructing the zope interface which the mailman CLI uses as well, but that turned out to be very complicated.
So I added some debugging to cli_members.py which is not ideal but better than adding to the code behind the server process.
for address in addresses: if not hasattr(address, 'email'): print(address)
yields there indeed being one address which is
None
.for member in list(roster.members): if member.address is None: print(member) print(member.user) print(member.user_id)
yields:
<Member: None on kde@lists.opensuse.org as MemberRole.member>` <User "DJR" (288462282097074430330836705058388050936) at 0x7fe04109a950> 127136
Taking this back to SQL, it seems there are no entries in the
address
table with thatuser_id
at all.It seems the user is subscribed to other lists as well:
SELECT * FROM member WHERE user_id = 127136;
.However, members with no address reference seem to be a relatively common occurrence:
SELECT * FROM member WHERE address_id IS NULL;
- hence I'm not sure this is the right lead and remain with the question what the issue with this specific user and mailing list is.
A test that comes to my mind: unsubscribe and subscribe again and see what happens.
Updated by krop 26 days ago
crameleon wrote in #note-3:
Taking this back to SQL, it seems there are no entries in the
address
table with thatuser_id
at all.It seems the user is subscribed to other lists as well:
SELECT * FROM member WHERE user_id = 127136;
.However, members with no address reference seem to be a relatively common occurrence:
SELECT * FROM member WHERE address_id IS NULL;
- hence I'm not sure this is the right lead and remain with the question what the issue with this specific user and mailing list is.
Is delivery enabled for these users?
Updated by crameleon 15 days ago
Is delivery enabled for these users?
According to
SELECT member.user_id,delivery_status FROM preferences INNER JOIN member ON preferences.id = member.preferences_id WHERE member.address_id IS NULL;
some have delivery status 1, some 2, some none at all.
A mapping of these numbers can be found here: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/interfaces/member.py#L40.