Search results for "sapiro" - lists.mailman3.org

[MM3-users] Re: problem configuring mailman3 on debian bullseye

by Servizio Informatico U.I.C.I. Sezione territoriale di Brescia

Hi, Thank you. I discovered tha I removed all templates but in the db table the template was not removed. It was pointing to localhost and this was the problem. Thanks to all for help! Roberto Burceni Servizio informatico sezionale Tel. 0302209417 (lunedì e giovedì mattina dalle 9:00 alle 13:00, martedì emercoledì pomeriggio dalle 14:00 alle 18:00 E-mail: servizioinformatico(a)uicibrescia.it Sito web: https://www.uicibrescia.it Il 16/03/23 04:20, Mark Sapiro ha scritto: > On 3/15/23 09:55, Odhiambo Washington wrote: >> On Wed, Mar 15, 2023 at 7:10 PM Servizio Informatico U.I.C.I. Sezione >> territoriale di Brescia <servizioinformatico(a)uicibrescia.it> wrote: >> >>> Hi, >>> >>> I created a template but after some tests I deleted it. >>> >>> Now I created only a standard list without modifying any templates. >>> >>> So they are the standard templates coming with the distribution. I >>> did not >>> change also the language >>> >> Maybe you can start by deleting any templates in postorius_emailtemplate >> table in the DB? > > There shouldn't be any, but if the issue is with accessing postorius > templates, that might make it worse. > > If you want only the system default templates, you could do this > database query to remove any non-defaults: > > DELETE FROM templates; > > That will ensure that you aren't accessing Postorius for any templates. >

3 years, 1 month

[MM3-users] Re: Can't post to my own list from HyperKitty

by MegaBrutal

Mark Sapiro <mark(a)msapiro.net> ezt írta (időpont: 2025. ápr. 9., Sze, 4:49): > ``` > $ mailman shell > Use commit() to commit changes. > Use abort() to discard changes since the last commit. > Exit with ctrl+D does an implicit commit() but exit() does not. > > >>> um = getUtility(IUserManager) > >>> usr = um.get_user('user(a)example.com') # any of the three addresses > >>> usr.addresses > prints a list of the 3 addresses. These are indexed as 0, 1, 2 > >>> usr.preferred_address > prints the preferred address. If this is the one you want to delete, do > >>> usr.preferred_address = usr.addresses[n] # n is the index of one > you want > >>> del usr.addresses[n] # n is the index of the address you don't want > >>> usr.addresses.remove(n) # n is the index of the address you don't > want > >>> commit() > ``` Thanks, I successfully removed my unwanted address, so it now doesn't appear anywhere. (Looks like .remove(n) wasn't needed, it only gave an exception, and the settings were saved even without commit() – which is concerning because I would have assumed that I can cancel transactions by omitting it.) However, the problem still persists: I can't post to the list from HyperKitty. In this regard, nothing has changed since my original report. I'm subscribed to the list with my primary, preferred address, which is the GMail address right now.

1 year

[MM3-users] Re: mail loops back to myself

by Florian Sukup

On 6/9/25 20:54, Mark Sapiro wrote: > On 6/9/25 05:06, Florian Sukup wrote: >> >> The setup has historic reasons. However I can eliminate >> reverse.rrr.com completely and replace it by host.xxx.com. Right now >> reverse.rrr.com has an A-record pointing to the host's ip address. > > Eliminating reverse.rrr.com completely and replacing it by host.xxx.com > would be good. This will help. > First step is done: I replaced reverse.rrr.com by host.xxx.com the DNS zones of all domain I use. Tomorrow I will have the rDNS record be rewritten by my ISP. > Also if I look up the A record for reverse.rrr.com either locally or at > aaron.ns.cloudflare.com there isn't one. This will be moot if you > replace reverse.rrr.com with host.xxx.com. > reverse.rrr.com is not the real name ... > > >>> What is the output from `postconf -n`? >>> >> >> alias_database = hash:/etc/aliases >> alias_maps = hash:/etc/aliases >> append_dot_mydomain = no >> biff = no >> compatibility_level = 2 >> inet_interfaces = all >> inet_protocols = all >> local_recipient_maps = proxy:unix:passwd.byname $alias_maps >> hash:/var/lib/mailman3/data/postfix_lmtp >> mailbox_size_limit = 0 >> message_size_limit = 0 >> mydestination = localhost, localhost.localdomain, arvak > > This needs to include $myhostname > I don't want to receive any emails like ...(a)host.xxx.com . So I thought removing host.xxx.com from $mydestination is a good idea. Is there any other solution for that? Florian.

10 months, 1 week

[MM3-users] Re: High memory usage

by Philip Colmer

On Thu, 17 Feb 2022 at 01:02, Mark Sapiro <mark(a)msapiro.net> wrote: > On 2/16/22 00:18, Philip Colmer wrote: > > Thank you for the replies from Mark and Stephen. > > > > One of the reasons why Prasanth & I are concerned with this specific > system > > is because the first time memory usage crept up, it got to the point > where > > oomkiller stepped in and, as is usual for that particular mechanism, one > of > > the processes it killed was sshd, thus removing access to the system :(. > I > > know that oomkiller can be tuned to stop it killing processes like sshd > but > > it will, nevertheless, start killing *some* processes if it sees an out > of > > memory situation. > > > It sounds like there is a memory leak somewhere. This is an issue with > some versions of Python. I know both Python 3.10.2 and 3.9.10 were > released ahead of schedule to fix this. See > https://bugs.python.org/issue46347 Thanks, Mark. We're using Python 3.8; I've looked at the open issues and don't immediately see any that might be memory-leak related in a way that would affect Mailman 3. That said, there are quite a few libraries and other "moving parts" involved in this project so we're going to try and track memory usage over time by process or similar to see if we can see whether or not this is a leak and, if it is, what the likeliest culprit might be. Philip

4 years, 2 months

[MM3-users] Re: Mails are stuck in Mailman Pipeline Queue

by Shashikanth Komandoor

Thank you Mark. This solution worked fine for me. On Sun, Mar 27, 2022 at 9:58 AM Mark Sapiro <mark(a)msapiro.net> wrote: > On 3/26/22 21:01, Shashikanth Komandoor wrote: > > > > But the below trace back is observed during mailman service stopping: > > > This doesn't say much ... > > > ...> Mar 27 09:01:22 2022 (5864) Uncaught runner exception: > > Mar 27 09:01:22 2022 (5864) Traceback (most recent call last): > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 173, in _one_iteration > ... > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 114, in signal_handler > > raise RunnerInterrupt > > mailman.interfaces.runner.RunnerInterrupt > > Mar 27 09:01:22 2022 (5864) SHUNTING: 1648351882.6693938+ > > c2e6ed709646a7680c73059b52d2f0451836e591 > > Mar 27 09:01:22 2022 (5864) digest runner exiting. > > Above, digest runner was interrupted in processing and shunted the > message it was working on. > > and below, pipeline runner was interrupted in processing and shunted the > message it was working on. > > > Mar 27 09:01:22 2022 (5860) Uncaught runner exception: > > Mar 27 09:01:22 2022 (5860) Traceback (most recent call last): > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 173, in _one_iteration > > self._process_one_file(msg, msgdata) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 266, in _process_one_file > > keepqueued = self._dispose(mlist, msg, msgdata) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/runners/pipeline.py", > > line 37, in _dispose > > process(mlist, msg, msgdata, pipeline) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/pipelines.py", > > line 50, in process > > handler.process(mlist, msg, msgdata) > > File "/var/lib/mailman/venv/lib64/python3.6/site-packages/ > > mailman/handlers/member_recipients.py", line 84, in process > > for member in mlist.regular_members.members > > File "/var/lib/mailman/venv/lib64/python3.6/site-packages/ > > mailman/handlers/member_recipients.py", line 83, in <genexpr> > > recipients = set(member.address.email > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py", > > line 239, in members > > yield from self._get_members(DeliveryMode.regular) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/roster.py", > > line 226, in _get_members > > if member.delivery_mode in delivery_modes: > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py", > > line 205, in delivery_mode > > return self._lookup('delivery_mode') > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/model/member.py", > > line 167, in _lookup > > pref = getattr(self.address.preferences, preference) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py", > > line 287, in __get__ > > return self.impl.get(instance_state(instance), dict_) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/attributes.py", > > line 723, in get > > value = self.callable_(state, passive) > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py", > > line 760, in _load_for_state > > session, state, primary_key_identity, passive > > File "<string>", line 1, in <lambda> > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/orm/strategies.py", > > line 850, in _emit_lazyload > > session.query(self.mapper), primary_key_identity > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/sqlalchemy/ext/baked.py", > > line 603, in _load_on_pk_identity > > setup, tuple(elem is None for elem in primary_key_identity) > > The above says the runner was doing a database lookup. This may be a > coincidence or there may be some database locking issue that underlies > the issue with the pipeline runner. > > > > File > "/var/lib/mailman/venv/lib64/python3.6/site-packages/mailman/core/runner.py", > > line 114, in signal_handler > > raise RunnerInterrupt > > mailman.interfaces.runner.RunnerInterrupt > > Mar 27 09:01:22 2022 (5860) SHUNTING: 1648351882.8537986+ > > 9bf59cb23a71a4bae65536bfdbec0abb261adaa0 > > Mar 27 09:01:22 2022 (5860) pipeline runner exiting. > > > I suggest doing the following assuming your Mailman database is not > sqlite3 (if it is, just do step 2): > > 1) Stop mailman core and maybe other mailman services too. > 2) Assuming the two shunted messages are still in Mailman's shunt queue, > run `mailman unshunt` to unshunt them. If there are more shunted > messages, inspect them with `mailman qfile` to see if you want them, > They may be spam. > 3) Restart your database server. > 4) Start Mailman core and any other stopped services. > > Also, look in the database server logs for any issues. > > -- > Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > _______________________________________________ > 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 & Regards, Shashi Kanth.K 9052671936

4 years

[MM3-users] Re: Walk-thru for Ubuntu Bionic Mailman 3 Full setup

by kisner＠live.com

Mark Sapiro wrote: > On 7/9/22 8:48 AM, kisner(a)live.com wrote: > > Thanks! > > OK, ran through again on a vanilla Debian 11.3 install, got this error (I'll try to create the directory and see if I can get past it): > > (venv) mailman@lists:~$ mailman-web migrate > > Traceback (most recent call last): > > File "/usr/lib/python3.9/logging/config.py", line 564, in configure > > handler = self.configure_handler(handlers[name]) > > File "/usr/lib/python3.9/logging/config.py", line 745, in configure_handler > > result = factory(**kwargs) > > File "/usr/lib/python3.9/logging/handlers.py", line 445, in __init__ > > logging.FileHandler.__init__(self, filename, mode=mode, > > File "/usr/lib/python3.9/logging/__init__.py", line 1142, in __init__ > > StreamHandler.__init__(self, self._open()) > > File "/usr/lib/python3.9/logging/__init__.py", line 1171, in _open > > return open(self.baseFilename, self.mode, encoding=self.encoding, > > FileNotFoundError: [Errno 2] No such file or directory: '/opt/mailman/web/logs/mailmanweb.log' > > Creation of the directory is documented. From > https://docs.mailman3.org/en/latest/install/virtualenv.html#initial-configur... > # Make sure that this directory is created or Django will fail on start. > LOGGING['handlers']['file']['filename'] = > '/opt/mailman/web/logs/mailmanweb.log' My bad, I missed that. Maybe pull that line out of the config comments and put it in the instructions below? That wasn't the show stopper, though, that I could figure out, it was the other bug. I'm glad someone already reported it and fixed it.

3 years, 9 months

[MM3-users] Re: Digests not working correctly

by Joel Lord

I ran the "/usr/local/bin/mailman digests --periodic" again, sadly without the --verbose, and it kicked out the digests as it ought to have the first time. Now I have to wait for some list traffic to come in to "recharge" the digests so I have something to test with again. -Joel On 6/13/2023 1:46 PM, Mark Sapiro wrote: > On 6/13/23 09:42, Joel Lord wrote: >> Now I'm on one of the lists in digest mode and I can see that it's a >> mess. Periodic digests are definitely NOT working, so I'll lay that >> out here. >> ... >> root@host2:/# grep digests /var/log/cron.log >> Jun 11 23:00:01 host2 CRON[1632765]: (lists) CMD >> (/usr/local/bin/mailman digests --periodic) >> Jun 12 23:00:01 host2 CRON[2177286]: (lists) CMD >> (/usr/local/bin/mailman digests --periodic) > > > OK. > >> root@host2:/home/members/directory# su - lists >> lists@host2:~$ /usr/local/bin/mailman digests --periodic >> lists@host2:~$ ls var/lists/<list>/ >> digest.mmdf > > > If there is nothing in Mailman's mailman.log, I don't know what the > issue is unless the list's digest_send_periodic flag is False. > > >> How can I try and track this down? > > > Try manually running > ``` > /usr/local/bin/mailman digests --periodic --verbose > ``` > to get more info. Also try > ``` > /usr/local/bin/mailman digests --send --verbose > ``` > to see what it reports and whether it sends the digest. > -- Joel Lord

2 years, 10 months

[MM3-users] Change to content filtering collapse alternatives - was: Re: Mailman shutting down Hyperkitty: Request too large

by Stephen J. Turnbull

Mark Sapiro writes: > That said, the effect on the OP's case, which may be more common, may be > harmful depending on list and Mailman config. > > The original message from the OP (edited) is > ``` > Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1" Ouch, that's a mess. First, unless you elided it, it's missing the required type parameter. Despite being required, it's basically an optimization and in most cases will not be much of one. So that's not really a big deal. Second, the Content-IDs are malformed. They are supposed to have the form of message IDs. Also not a big deal, they're close enough for government work. The big problem is I have no idea what the semantics of multipart/related text/plain image/jpeg should be. Throwing away the image data seems like it would be the right thing to do according to RFC 2387, which delegates rendering of the entire multipart/related entity to the root entity. But if that were the desired result of the author of the original message, it's straightforward to achieve by inverting the related and alternative parts. And (at least for image content) I would think that would be a rare intention. I don't see an obvious way to resolve this without checking what popular MUAs do with the various possibilities. So as long as your patch does the expected thing, it's the minimal solution. Steve

1 year, 2 months

[MM3-users] Re: Weird hourly indexing error

by Mark Dadgar

On May 5, 2020, at 9:21 AM, Mark Sapiro <mark(a)msapiro.net> wrote: > > On 5/5/20 8:55 AM, Mark Dadgar wrote: >> I moved my mail server to a Digital Ocean droplet. I basically installed all the appropriate packages and then rsync’d everything that matters from my metal server up to the cloud instance. Everything more or less works fine. >> >> However, I am now getting this hourly error - see below. > ... >> [ERROR/MainProcess] Failed indexing 1 - 1000 (retry 5/5): Term too long (> 245): XSUBJECT95251413 (pid 36301): Term too long (> 245): XSUBJECT95251413 >> Traceback (most recent call last): >> File "/usr/lib/python3/dist-packages/haystack/management/commands/update_index.py", line 97, in do_update >> backend.update(index, current_qs, commit=commit) >> File "/usr/local/lib/python3.8/dist-packages/xapian_backend.py", line 488, in update >> database.replace_document(document_id, document) >> xapian.InvalidArgumentError: Term too long (> 245): XSUBJECT95251413 > > > This error comes from Xapian. It is due to a (new) message in your > archive that contains a 'word' longer than 245 characters. > > There is a PR at > <https://github.com/notanumber/xapian-haystack/pull/181> that addresses > this plus another suggested fix in that PR's comment thread. Thanks. I guess I wait for them to roll the fix in and the ubuntu maintainers to pick it up. > Note: I got there by googling "xapian term too long" which gave > <https://github.com/notanumber/xapian-haystack/issues/153> as the first > hit and that led me to the above. Yeah, that would have been smarter. - Mark ----- mark(a)pdc-racing.net | 408-348-2878

5 years, 11 months

[MM3-users] Re: Cron Error: <mailman@gw> /opt/mailman/mm/bin/django-admin runjobs monthly

by Odhiambo Washington

On Wed, Feb 1, 2023 at 8:31 PM Mark Sapiro <mark(a)msapiro.net> wrote: > On 1/31/23 23:33, Odhiambo Washington wrote: > > Is this a race condition? > > > > <CUT> > > ERROR OCCURED IN JOB: update_and_clean_index (APP: hyperkitty) > > Traceback (most recent call last): > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/django_extensions/management/commands/runjobs.py", > > line 40, in runjobs > > job().execute() > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/jobs/update_and_clean_index.py", > > line 37, in execute > > run_with_lock(update_index, remove=True) > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/hyperkitty/lib/utils.py", > > line 181, in run_with_lock > > log.exception("Failed to update the fulltext index: %s", e) > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/flufl/lock/_lockfile.py", > > line 470, in __exit__ > > self.unlock() > > File > > > "/opt/mailman/mm/venv/lib/python3.9/site-packages/flufl/lock/_lockfile.py", > > line 420, in unlock > > raise NotLockedError('Already unlocked') > > flufl.lock._lockfile.NotLockedError: Already unlocked > > <CUT> > > > Yes, it is a race between the monthly hyperkitty update_and_clean_index > job and the hourly hyperkitty update_index job > Okay. This is a bit off from my understanding. What is the cause and how do I mitigate it? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-)

3 years, 2 months

Search results for query "sapiro"