Search results for "Postorius" - Mailman-users

Re: Column 'starting_email_id' cannot be null

by Odhiambo Washington

On Mon, Aug 18, 2025 at 11:32 AM kroerig--- via Mailman-users < mailman-users(a)mailman3.org> wrote: > Hello, > > after upgrading from Debian 11 to Debian 12 achiving incoming mails always > fails with > > Traceback (most recent call last): > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 581, in get_or_create > return self.get(**kwargs), False > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 435, in get > raise self.model.DoesNotExist( > > During handling of the above exception (Thread matching query does not > exist.), another exception occurred: > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 73, in execute > return self.cursor.execute(query, args) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 209, in > execute > res = self._query(query) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 316, in > _query > self._do_get_result(db) > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 147, in > _do_get_result > self._result = result = self._get_result() > File "/usr/lib/python3/dist-packages/MySQLdb/cursors.py", line 349, in > _get_result > return self._get_db().store_result() > > During handling of the above exception ((1048, "Column 'starting_email_id' > cannot be null")), another exception occurred: > File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", > line 47, in inner > response = get_response(request) > File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line > 181, in _get_response > response = wrapped_callback(request, *callback_args, **callback_kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/http.py", > line 40, in inner > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 117, in _decorator > return func(request, *args, **kwargs) > File "/usr/lib/python3/dist-packages/django/views/decorators/csrf.py", > line 54, in wrapped_view > return view_func(*args, **kwargs) > File "/usr/lib/python3/dist-packages/hyperkitty/views/mailman.py", line > 163, in archive > add_to_list(mlist_fqdn, msg) > File "/usr/lib/python3/dist-packages/hyperkitty/lib/incoming.py", line > 153, in add_to_list > email.save() > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 763, in save_base > pre_save.send( > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 180, in send > return [ > File "/usr/lib/python3/dist-packages/django/dispatch/dispatcher.py", > line 181, in <listcomp> > (receiver, receiver(signal=self, sender=sender, **named)) > File "/usr/lib/python3/dist-packages/hyperkitty/signals.py", line 48, in > Email_on_pre_save > kwargs["instance"].on_pre_save() > File "/usr/lib/python3/dist-packages/hyperkitty/models/email.py", line > 239, in on_pre_save > thread, _thread_created = Thread.objects.get_or_create( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 588, in get_or_create > return self.create(**params), True > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 453, in create > obj.save(force_insert=True, using=self.db) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 739, in save > self.save_base(using=using, force_insert=force_insert, > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 776, in save_base > updated = self._save_table( > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 881, in _save_table > results = self._do_insert(cls._base_manager, using, fields, > returning_fields, raw) > File "/usr/lib/python3/dist-packages/django/db/models/base.py", line > 919, in _do_insert > return manager._insert( > File "/usr/lib/python3/dist-packages/django/db/models/manager.py", line > 85, in manager_method > return getattr(self.get_queryset(), name)(*args, **kwargs) > File "/usr/lib/python3/dist-packages/django/db/models/query.py", line > 1270, in _insert > return query.get_compiler(using=using).execute_sql(returning_fields) > File "/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py", > line 1416, in execute_sql > cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 66, in execute > return self._execute_with_wrappers(sql, params, many=False, > executor=self._execute) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 75, in _execute_with_wrappers > return executor(sql, params, many, context) > File "/usr/lib/python3/dist-packages/django/db/backends/utils.py", line > 84, in _execute > return self.cursor.execute(sql, params) > File "/usr/lib/python3/dist-packages/django/db/backends/mysql/base.py", > line 78, in execute > raise IntegrityError(*tuple(e.args)) > > Exception Type: IntegrityError at /hyperkitty/api/mailman/archive > Exception Value: (1048, "Column 'starting_email_id' cannot be null") > > Postorius Version 1.3.8 > HyperKitty Version 1.3.7 > > Any ideas how to fix this? > > Klauas It looks like you did not run some migrations. However, because this is packaged Mailman3, I am not sure I know how to do that. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

3 months, 3 weeks

Re: Rejecting held emails

by Mark Sapiro

On 04/26/2018 08:43 AM, Darren Smith wrote: > > We recently had a phishing message make it through our spam filters and > arrive at a mailing list. The good news is that since it was not from a > list member it was in the held message queue. > > I was able to find the message in the var/messages directory by searching > for a keyword in the subject. However, after rejecting the message from > Postorius, the message doesn't seem to be removed from the var/messages > directory. Do you mean Reject and not Discard? Phishing/Spam should never be "rejected" for backscatter reasons. Reject should only be used for somehow inappropriate posts from known people. > Is this expected behavior? I know that infosec people won't be too happy > about a phishing email sitting around on our disk. (Infosec guys are > notoriously paranoid. :) ) > > Is there some sort of cleanup process that would remove these messages? If > not, does this pose an issue where over time disk usage will creep up? This > could be a pretty significant problem if that is the case. It's not the behavior I would "expect", but it is the way it currently works, and yes, all your concerns are valid. This is <https://gitlab.com/mailman/mailman/issues/257> which I just edited to note that in addition to not removing the pending db entry, the message isn't removed either. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

7 years, 7 months

Re: Confusing mailman user model

by Mark Sapiro

On 7/19/20 8:10 AM, Gilles Filippini wrote: > Hi, > > I'm trying to understand the Mailman user model, and I'm confused about > the respective roles of tables 'auth_user' and 'user'. auth_user is a Django auth table. These are the users listed in the Django admin web UI. user is Mailman core's users. > Both have an 'id' column referred to as 'user_id' when used as a foreign > key. But there seems to be no relation at all between them as they use > different ids for the same user. Right, they are unrelated. > Our mailman server was migrated from mailman2 to mailman3 about 1.5 year > ago, and there is an inconsistency I'd like to fix: > 2 of our users have a registered Mailman account with their respective > email addresses in table 'auth_user', but these very same addresses in > the 'address' table are linked to another old admin account in the > 'user' table. Their Mailman account is the 'old' one. the auth_user account is a Django account > > Then if add one of these addresses as a domain owner, it it the old > admin address which is selected instead. How could I fix that? That's because domain owner in a Mailman thing and involvs the Mailman user. You could delete the Django users via the Django admin UI and then re-register them via Postorius. That *might* work. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

5 years, 4 months

Re: Archive Policy not reflecting in Hyperkitty

by Nathan Dixon

Ok, I've figured out how to run the job manually. And here's the error I'm getting (list name and domain has been changed to <listname> and <domain>.com for security reasons): From within mailman-web container: bash-4.4# python3 manage.py runjob sync_mailman ERROR OCCURED IN JOB: sync_mailman (APP: None) START TRACEBACK: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) psycopg2.IntegrityError: null value in column "description" violates not-null constraint DETAIL: Failing row contains (4, <listname>@<domain>.com, <LISTNAME>, null, [<LISTNAME>] , 1, 2019-03-12 10:23:20.293675+00, <listname>.<domain>.com). The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.6/site-packages/django_extensions/management/commands/runjob.py", line 35, in runjob job().execute() File "/usr/lib/python3.6/site-packages/hyperkitty/jobs/sync_mailman.py", line 35, in execute sync_with_mailman() File "/usr/lib/python3.6/site-packages/hyperkitty/lib/mailman.py", line 131, in sync_with_mailman mlist.update_from_mailman() File "/usr/lib/python3.6/site-packages/hyperkitty/models/mailinglist.py", line 192, in update_from_mailman self.save() File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 718, in save force_update=force_update, update_fields=update_fields) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 748, in save_base updated = self._save_table(raw, cls, force_insert, force_update, using, update_fields) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 812, in _save_table forced_update) File "/usr/lib/python3.6/site-packages/django/db/models/base.py", line 861, in _do_update return filtered._update(values) > 0 File "/usr/lib/python3.6/site-packages/django/db/models/query.py", line 712, in _update return query.get_compiler(self.db).execute_sql(CURSOR) File "/usr/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1383, in execute_sql cursor = super().execute_sql(result_type) File "/usr/lib/python3.6/site-packages/django/db/models/sql/compiler.py", line 1065, in execute_sql cursor.execute(sql, params) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 68, in execute return self._execute_with_wrappers(sql, params, many=False, executor=self._execute) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 77, in _execute_with_wrappers return executor(sql, params, many, context) File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) File "/usr/lib/python3.6/site-packages/django/db/utils.py", line 89, in __exit__ raise dj_exc_value.with_traceback(traceback) from exc_value File "/usr/lib/python3.6/site-packages/django/db/backends/utils.py", line 85, in _execute return self.cursor.execute(sql, params) django.db.utils.IntegrityError: null value in column "description" violates not-null constraint DETAIL: Failing row contains (4, <listname>@<domain.com>, <LISTNAME>, null, [LISTNAME] , 1, 2019-03-12 10:23:20.293675+00, <listname>.<domain>.com). END TRACEBACK So it looks like there's a null in one of the columns. This list was created using the Postorius interface. I had sent a couple of messages to the list while the archive attribute was set to public and then I changed it to private and sent some more test mails to it. Hopefully this will help us find a solution to this. Thanks On Tue, 7 May 2019 at 10:40, Nathan Dixon <nathan.dixon(a)evadon.com> wrote: > I'm not sure if it's also related, but within the mailman-web and > mailman-core docker containers, crontab -e only shows these entries: > # do daily/weekly/monthly maintenance > # min hour day month weekday command > */15 * * * * run-parts /etc/periodic/15min > 0 * * * * run-parts /etc/periodic/hourly > 0 2 * * * run-parts /etc/periodic/daily > 0 3 * * 6 run-parts /etc/periodic/weekly > 0 5 1 * * run-parts /etc/periodic/monthly > > And all of those folders are empty. > > I'm not sure where the synchronisation task for Hyperkitty should actually > being run from? > > Thank you > > On Tue, 7 May 2019 at 10:20, Nathan Dixon <nathan.dixon(a)evadon.com> wrote: > >> The change to the archiving policy aren't reflected in Hyperkitty after >> many days for all the lists. >> >> The only error that I am seeing in the /web/mailmanweb.log is: >> INFO 2019-05-02 14:16:55,062 38 hyperkitty.tasks AsyncTask task >> "<function unlock_and_call at 0x7f5d8851f048>" with args "(<function >> update_from_mailman at 0x7f5d88544a60>, 'task:status:%s:%s', '<list >> address>')" and kwargs "{}" finished with errors. >> >> I'm not sure if that could be related? (I have changed the actual list >> address to <list address> for security reasons) >> >> Thank you >> >> On Sat, 4 May 2019 at 16:24, Abhilash Raj <maxking(a)asynchronous.in> >> wrote: >> >>> On Fri, May 3, 2019, at 8:38 AM, Nathan Dixon wrote: >>> > So the issue I am seeing is that when I set a lists archive policy to >>> > prviate, it isn't reflecting that in Hyperkitty. >>> > >>> > I am running the docker installation of Mailman, postorius and >>> hyperkitty. >>> > So I go into the docker instance of mailman-core and run this: >>> > >>> > python3 manage.py shell from hyperkitty.models.mailinglist import >>> > MailingList MailingList.objects.all().values_list('name', >>> 'archive_policy') >>> > >>> > And all my lists are showing '2', regardless of how I set the mailing >>> list >>> > archive policy. >>> > >>> > This might be a duplicate of >>> > >>> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/… >>> > >>> > Am I missing something in my install? Or is this a bug? >>> >>> It can take upto an hour for this change to reflect in Hyperkitty. Did >>> you wait >>> for that long? >>> >>> This happens because Hyperkitty stores it's own data, and queries Mailman >>> Core periodically to fetch updates every hour. In future, we might be >>> able to >>> do this in more realtime fashion by using an event based pub/sub model. >>> But, >>> we are not there yet. >>> >>> >>> > >>> > Many thanks for your attention, >>> > >>> > -- >>> > >>> > *Nathan Dixon* MEng >>> > Senior Software Architect >>> > m: +44 (0)7402 690311 >>> > >>> > t: +44 (0)20 81231252 >>> > e: nathan.dixon(a)evadon.com >>> > w: www.evadon.com >>> > >>> > This e-mail and any attachments are confidential and may be protected >>> by >>> > legal, professional or other privilege. If you are not the intended >>> > recipient you should not store it, copy it, re-transmit it, use it or >>> > disclose its contents, but should return it to the sender immediately >>> and >>> > delete your copy from your system. The views expressed are those of the >>> > sender and not necessarily those of Evadon. Please note that whilst we >>> scan >>> > all e-mails for viruses we cannot guarantee that any e-mail is >>> virus-free. >>> > Please be advised that we expressly reserve the right to monitor email >>> > content for the purposes of ensuring compliance with legal >>> requirements and >>> > company policies and your sending to, or receiving from, us of any >>> email >>> > constitutes your agreement to these terms. >>> > >>> > >>> > Evadon Dynamics Limited, registered in England No. 09494097. Registered >>> > Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, >>> Sheffield, >>> > S1 2BJ >>> > _______________________________________________ >>> > Mailman-users mailing list -- mailman-users(a)mailman3.org >>> > To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>> > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>> > >>> >>> -- >>> thanks, >>> Abhilash Raj (maxking) >>> _______________________________________________ >>> Mailman-users mailing list -- mailman-users(a)mailman3.org >>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>> >> >> >> -- >> >> *Nathan Dixon* MEng >> Senior Software Architect >> m: +44 (0)7402 690311 >> >> t: +44 (0)20 81231252 >> e: nathan.dixon(a)evadon.com >> w: www.evadon.com >> >> This e-mail and any attachments are confidential and may be protected by >> legal, professional or other privilege. If you are not the intended >> recipient you should not store it, copy it, re-transmit it, use it or >> disclose its contents, but should return it to the sender immediately and >> delete your copy from your system. The views expressed are those of the >> sender and not necessarily those of Evadon. Please note that whilst we scan >> all e-mails for viruses we cannot guarantee that any e-mail is virus-free. >> Please be advised that we expressly reserve the right to monitor email >> content for the purposes of ensuring compliance with legal requirements and >> company policies and your sending to, or receiving from, us of any email >> constitutes your agreement to these terms. >> >> >> Evadon Dynamics Limited, registered in England No. 09494097. Registered >> Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, >> S1 2BJ >> > > > -- > > *Nathan Dixon* MEng > Senior Software Architect > m: +44 (0)7402 690311 > > t: +44 (0)20 81231252 > e: nathan.dixon(a)evadon.com > w: www.evadon.com > > This e-mail and any attachments are confidential and may be protected by > legal, professional or other privilege. If you are not the intended > recipient you should not store it, copy it, re-transmit it, use it or > disclose its contents, but should return it to the sender immediately and > delete your copy from your system. The views expressed are those of the > sender and not necessarily those of Evadon. Please note that whilst we scan > all e-mails for viruses we cannot guarantee that any e-mail is virus-free. > Please be advised that we expressly reserve the right to monitor email > content for the purposes of ensuring compliance with legal requirements and > company policies and your sending to, or receiving from, us of any email > constitutes your agreement to these terms. > > > Evadon Dynamics Limited, registered in England No. 09494097. Registered > Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, > S1 2BJ > -- *Nathan Dixon* MEng Senior Software Architect m: +44 (0)7402 690311 t: +44 (0)20 81231252 e: nathan.dixon(a)evadon.com w: www.evadon.com This e-mail and any attachments are confidential and may be protected by legal, professional or other privilege. If you are not the intended recipient you should not store it, copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. The views expressed are those of the sender and not necessarily those of Evadon. Please note that whilst we scan all e-mails for viruses we cannot guarantee that any e-mail is virus-free. Please be advised that we expressly reserve the right to monitor email content for the purposes of ensuring compliance with legal requirements and company policies and your sending to, or receiving from, us of any email constitutes your agreement to these terms. Evadon Dynamics Limited, registered in England No. 09494097. Registered Office: Electric Works, Sheffield Digital Campus, 3 Concourse Way, Sheffield, S1 2BJ

6 years, 7 months

Re: mailman-web migrate fails with sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email

by Mark Sapiro

On 3/3/25 07:52, Stefan Bauer via Mailman-users wrote: > > trying to update mailman3 to lastest version, we fail during > > mailman-web migrate with: > > Operations to perform: > Apply all migrations: account, admin, auth, contenttypes, django_mailman3, > django_q, hyperkitty, postorius, sessions, sites, socialaccount > Running migrations: > Applying account.0006_emailaddress_lower...Traceback (most recent call > last): > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/utils.py", > line 89, in _execute > return self.cursor.execute(sql, params) > File > "/opt/mailman/venv/lib/python3.10/site-packages/django/db/backends/sqlite3/base.py", > line 328, in execute > return super().execute(query, params) > sqlite3.IntegrityError: UNIQUE constraint failed: account_emailaddress.email This issue is due to changes in Django allauth to prevent creating multiple addresses differing only in case. The problem is if you have such multiple addresses in your account_emailaddress table, this migration fails. There is a script at https://www.msapiro.net/scripts/UC_fix that will fix this. You may need to adjust the shebang and replace psycopg2 with sqlite3. See https://github.com/pennersr/django-allauth/issues/3019 perhaps starting at https://github.com/pennersr/django-allauth/issues/3019#issuecomment-1748028… > We found a workaround to fake the migration with > > migrate --fake You should fix the issue with the DB and run the migrations. > Could this be some duplicate users with same mail-address? This is not related to Mailman users. It is Django users. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 months, 1 week

Re: Performance of member listing [was: How to remove a nonmember...]

by Abhilash Raj

On Sat, Apr 18, 2020, at 8:25 AM, skenny(a)scss.tcd.ie wrote: > Well, it is quite possible that something is seriously wrong with my > configuration. > > The database backend is Postgres - not something I configured. It is > specified in my docker-compose file, which in turn is based on the > compose files at https://github.com/maxking/docker-mailman. > > (At one point I thought maybe the virtual machine I'm running on was > under-resourced. I've since doubled memory and the number of CPUs but > that hasn't really improved things.) > > I'm wondering where to go next - try tweaking the Postgres config, > switch to SQLlite .... Switching to SQLite will definitely degrade performance, unless Postgres database is being weird. I haven't observed any issues reported in the past for the performance. I am a little confused which part are we talking here about being too slow. You mentioned two things: - The python script you wrote using MailmanClient - Listing non-members/members - Delete a non-member via Postorius. It would be nice to establish which specific view is being slow so I can dig more into it. Can you paste the URL and action which takes 2.5minutes as you mentioned? > > Thanks for giving time to helping me with this, much appreciated. > > Stephen > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > -- thanks, Abhilash Raj (maxking)

5 years, 7 months

Missing Base64 encoding from control message reply

by Stephen J. Turnbull

lists-mailman3(a)janaberger.de writes: > I have a setup with GNU Mailman 3.3.8 where a user tried to > subscribe. When replying to the "confirm" message, the user > received a completely garbled response, like so: > > N?z?????zf???&???j?????u?[zZ0:???v???,j?z???k?e?0 > 4D???r?^b??r?????*'???y????{ax?L?X????0:???v???,j?z???k?d?m?-???zz?rn??l]y+???-E?( > ?^N??'??M???t???Mz?????^i?????}?o?\????6sN?zf??????r??z?????????b?{h?????f?r?ne== To diagnose, we really need to see that in context of the raw message as received by the user. > The user then forwarded the .eml file to me, which clearly shows > the contents of the mail as plain text while being announced as > base64 (Content-Transfer-Encoding: base64): It also clearly doesn't show anything like the mojibake above. What is the relation between the two? While the problems could be related to Mailman, it could also be any MTA along the way or the user's mail client. I suspect that the .eml file has been significantly altered by intervening software. As far as I know, the Python email package does not MIME-encode plain ASCII text as you see in the email's subject. The only other thing I can think of is it might have something to do with your internationalization settings. What is the default language of the list? (This is available in Postorius.) Have you changed the default encoding for English on your site? (I think you need to look in mailman.cfg for this.) What is the default language of the site? Steve

2 years, 2 months

Re: Database deadlock when trying to delete a member.

by Simon Coggins

> On 18 Mar 2021, at 5:05 pm, Abhilash Raj <maxking(a)asynchronous.in> wrote: > > Hi Simon, > > > On Mar 17, 2021, at 10:16 PM, Simon Coggins <s.coggins(a)cqu.edu.au> wrote: > > > > Hi, > > > > I’ve got a strange error. I migrated from mailman 2.1 to 3 using the migration guide on the website and things have been working fine. But I’m in the process of testing the new syncmembers command to replace some inhouse mailman API code we wrote. I’ve tracked my problem down to what appears to be a deadlock in the postgresql database. When trying to delete certain users the SQL query hangs and never returns. > > > > After doing some tracing and tracking it down to the database, I enabled DB logging of all queries and saw that the following query was never returning: > > > > DELETE FROM member WHERE member.id = 166814 > > > > If I try to run it manually I get the same issue, in psql it never returns. > > mailman=# explain analyze DELETE FROM member WHERE member.id = 166814; > > [… 60 seconds passes…] > > ^CCancel request sent > > ERROR: canceling statement due to user request > > CONTEXT: while deleting tuple (2998,72) in relation "member" > > I’m just wondering if there are any commands or scripts I can run to verify the database and it’s constraints to see if there is some error in the database data? Or where you’d recommend I go from here? It only impacts the user on this specific list. If I add this user to another list and remove them, everything works fine. > > Are you able to retrieve that Member object using API? > > This[1] the Python code which would try to delete a Member object and I > am assuming is being called from syncmembers command. I am not entire > sure about what would cause the database to hang, if there was some database > constraint that failed, I would imagine some error to be returned. > > [1]: https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/model/member.p… > Ok I think I’m getting closer. It appears to be an open transaction that is locking the database record. While mailman is running, if I try to execute "DELETE FROM member WHERE member.id = 166507;” on the mailman table in psql the query hangs and never returned. But if I shutdown mailman and try to run the query again, it executed immediately. So I’m pretty sure there is an open transaction that is causing the entry to be locked. > One thing you can try is see if you can unsubscribe the user using the API or > `mailman shell` command. > > You can unsubscribe from API by calling a `DELETE` method at > > http://localhost:9001/3.1/members/<member_id> > > This would give us some indication about whether there is some bug > in the implementation of syncmembers command or if there is something > else going on. > Trying via shell or via API to delete the user all fail and hang. I’m able to receive the user/membership/list data without any issue both via mailman command and via the API. > > > > This is on a test system so I can do various testing. I’m trying to find the root cause so that I can verify my production system isn’t impacted by the same thing. > > > > > > Setup Details: > > OS: Oracle Linux 7 (Redhat) > > Installed using pip via virtualenv talking to a local pgsql database on the same box. > > Data was migrated from a mailman 2.1 install into mailman3 using migration instructions on the website. > > > > PIP Modules versions: > > django-mailman3 1.3.5 > > mailman 3.3.3 > > mailman-hyperkitty 1.1.0 > > mailmanclient 3.3.2 > > postorius 1.3.4 > > psycopg2-binary 2.8.5 > > What is the version of sqlalchemy package? There is a new 1.4.0 version that came out recently > and is incompatible with Core right now. There are backwards incompatible changes which might > need some changes in Core to add support. > SQLAlchemy 1.3.19 > > > > RPM packages: > > postgresql12-12.6-1PGDG.rhel7.x86_64 > > postgresql12-server-12.6-1PGDG.rhel7.x86_64 > > postgresql12-libs-12.6-1PGDG.rhel7.x86_64 > > postgresql12-devel-12.6-1PGDG.rhel7.x86_64 > > > > > > -Simon > > > > > > _______________________________________________ > > Mailman-users mailing list -- mailman-users(a)mailman3.org > > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > > -- > thanks, > Abhilash Raj (maxking) > > > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ --- Simon Coggins, Principal Systems Engineer Digital Services Directorate CQUniversity, Lvl 6.14, 160 Ann Street Brisbane, QLD, 4000 Email: s.coggins(a)cqu.edu.au Web: http://www.cqu.edu.au/

4 years, 8 months

Re: Mailman Core 3.3.2 is now out

by Abhilash Raj

I missed it in the original email, but a full list of changes in this version is present here: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.… thanks, Abhilash On Fri, Nov 6, 2020, at 5:38 PM, Abhilash Raj wrote: > Hi Everyone, > > I am pleased to announce that with a week long delay from the planned date, > GNU Mailman Core 3.3.2 is now finally out. This release includes both bug fixes > and some new features. > > Some notable changes include: > - Support for inviting users to join mailing lists. > - New adddmembers, delmembers and syncmembers command to manage > membership from CLI. > - Addition of new REST API endpoints that return the count of held > messages and subscription requests of much faster page loads in > Postorius. > - Addition of support for filtering in some API endpoints like > Members and Subscription requests. > - Support for address= option in email join command to subscribe an > address other then sending address. > - Addition of who email command to lookup memberships. > - Expose emergency field for MailingList resource in REST API. > - Several bug fixes to support new major version of libraries like > dnspython, flufl.* etc. > > You can install it using: > > $ pip install --upgrade mailman > > The tarball for the release is available at PyPI: > > https://pypi.org/project/mailman/ > > Finally, many thanks to all the contributors who have helped make this > release a success! > > -- > Abhilash Raj (maxking) on behalf of Mailman Core team > -- thanks, Abhilash Raj (maxking)

5 years, 1 month

Getting Archives to work - new setup on Ubuntu 18.04 (with mailman3-full pkg)

by kelly.close＠lrewater.com

Happy New Year! I'm setting up my first Mailman 3 server and was delighted to find a distribution package for Ubuntu 18.04, since that's the environment I'm most familiar with working in, that installs an integrated mailman3-hyperkitty-postorius setup. The package install plus the additional config steps in the included README files have gotten me oh-so-very close! What isn't working yet are the archives, specifically the messages sent to lists showing up at .../mailman3/hyperkitty. I'm at a loss and I'm hoping maybe the folks on this list can help me bring it home. Messages are distributed to subscribers as they should be - subscribers can send from their emails or from the web site. People can subscribe, etc. It's all working great. Just no archives. I am able to successfully run these django-admin processes without errors (described here: http://docs.mailman3.org/en/latest/config-web.html#scheduled-tasks-required) I've run them all manually and then I've been running the minutely and hourly ones manually after each test message I send (haven't set up the actual cron jobs yet). I'm not sure what to try next or what info to provide here for help - can anyone suggest where I can look to see why archives aren't getting created, or let me know what information would be essential for me to post to get help on this? I'm using PostgreSQL for the database, Postfix for mail and Apache2 for the web server. Thanks for your time! ~Kelly

6 years, 11 months

Mailman-users search results for query "Postorius"