Search results for query "sapiro"
- 6241 messages
[MM3-users] Time Stand Still
by Barry Warsaw
Somewhen in the dark recesses of intarweb history, I found myself as the project leader for both Jython (née JPython) and GNU Mailman. I'd been involved with Jython since it was invented by Jim Hugunin around the time he came to work with us at Pythonlabs. I'd been contributing to Mailman since we inherited John Viega's Python-based Dave Matthews Band list server, and put it to use replacing python.org's Majordomo installation.
I'd enjoyed both projects, but knew I could not lead both, so I had to make a choice. I chose to turn over Jython to a team that's done a much better job over the years than I ever could have. Something about email, and especially the communication and collaboration patterns that it facilitates, really fascinated me. I know, I know, but we all have our lapses of sanity. Mine has lasted almost 20 years, a bit more than "momentary" perhaps.
I've rarely gotten paid to work on Mailman, but it did provide me some great opportunities. Most notably it led to my 10 year stint at Canonical. I was originally hired on there to integrate mailing lists with Launchpad, and Mailman was the obvious choice. I learned a ton doing that project, and working within the constraints of integrating the two Python-based systems, especially since Launchpad was originally not free software and Mailman was GPL'd. Later, the Zope-based Launchpad source code was released under the AGPL, making much of the monkeypatching unnecessary, but by then the system was solid and reliable, and you don't fix what's not broken.
Except, I guess I did. I took a lot of the lessons from that work, along with a good hard look at all the problems with Mailman 2, and began to break another cardinal rule of software development: second system syndrome. The result is Mailman 3. It took forever, and we're still not at complete feature parity with Mailman 2, but at least it's Real Enough to be used at many Real Sites, including python.org and lists.fedoraprojects.org.
It would be ridiculous for me to take significant credit for this. I have to acknowledge the amazing user community -- you! -- for all the support, patches, suggestions, feedback, patience, criticism, donations, and contributions that you've given to the project, and to me personally over the years. And my deepest gratitude goes to all the core developers that have stayed or come and gone, but most especially the current Cabal: Abhilash Raj, Aurelien Bompard, Florian Fuchs, Mark Sapiro, Stephen J. Turnbull, Terri Oda. You should know that each and every one of them is truly awesome, both in what they contribute technically, and in their amazing friendships. Mailman is infinitely better because of their involvement, and I've loved spending time with them over the years at the Pycon sprints, making releases and sharing teas and meals.
My blog is called We Fear Change, and that's humorously taken from a 90's bit in Mike Myer's excellent Wayne's World movie (a phrase actually uttered by the brilliant Dana Carvey as Garth). The irony of course is that while we all may fear change, it's the one constant thing we can count on. And in fact, we *require* change to thrive, because if you aren't changing, you aren't alive. Time, and being engaged with life's vagaries, means there's no alternative to change; it must be embraced.
And so, with a vague reference to the many (good!) changes in my personal and professional life, I'm announcing that I'm stepping down from the project leadership role of GNU Mailman, effective... nowish! And it's with unanimous agreement among the GNU Mailman Steering Committee (a.k.a. the Mailman Cabal), that we are announcing Abhilash Raj as the new project leader.
If you don't recognize Abhilash's name, you probably aren't paying attention, at least to Mailman 3. Abhilash came to us in 2013 as a Google Summer of Code student, and he's become one of the project's most valuable contributors. His list of accomplishments is long, and it includes everything from redesigning the website, to integrating CI with our GitLab build system, porting our code to the SQLAlchemy ORM, adding MySQL support, revving up adoption through his Docker images, along with his great coding work on Core, Postorius, HyperKitty, and mailmanclient.
This transition is good for the project too. Email, its defining protocols and standards, and its role in our daily lives, has changed profoundly since the early days of Mailman. A fresh perspective and enthusiasm will help keep Mailman relevant to the changing ways we -- especially the FLOSS and tech communities -- communicate.
Please join me in supporting Abhilash in every way possible as he takes over in this new role as project leader. I'll be here when and if needed, even as I create space in my "spare" time for... Something Else. I look forward to the vision that Abhilash will bring to the project, and I know that he will do a great job. To me, Mailman has always been about collaboration, and the best
way for it to succeed is for you to continue to contribute your insights, experiences, opinions, and skills with positive intention.
-Barry
https://www.wefearchange.org/
8 years, 6 months
[MM3-users] Re: E-mail every minute: "Cron <www-data@sharky5> ..."
by Robert Heller
At Mon, 8 Jul 2024 00:16:48 +0300 Odhiambo Washington <odhiambo(a)gmail.com> wrote:
>
> On Sun, Jul 7, 2024 at 8:43â¯PM Robert Heller <heller(a)deepsoft.com> wrote:
>
> > At Sun, 7 Jul 2024 19:48:02 +0300 Odhiambo Washington <odhiambo(a)gmail.com>
> > wrote:
> >
> > >
> > > On Sun, Jul 7, 2024 at 7:16âÃâ¬Ã¯PM Robert Heller <heller(a)deepsoft.com>
> > wrote:
> > >
> > > > At Sun, 7 Jul 2024 18:52:05 +0300 Odhiambo Washington <
> > odhiambo(a)gmail.com>
> > > > wrote:
> > > >
> > > > >
> > > > > On Sun, Jul 7, 2024 at 4:12ÃÆÃÆÃââÃÆÃââÃâìÃÆÃâÃâïPM Robert
> > Heller <heller(a)deepsoft.com>
> > > > wrote:
> > > > >
> > > > > > What am I missing? I *think* I have mailman3 *mostly* setup, but
> > there
> > > > > > are
> > > > > > still some configuration things that are missing, but I am not sure
> > > > how to
> > > > > > fix
> > > > > > them (the docs are NOT clear).
> > > > > >
> > > > >
> > > > > Which docs are you relying on?
> > > >
> > > > https://docs.mailman3.org/en/latest/config-web.html
> > > >
> > > > I presume these are the official docs for mailman3 -- maybe they
> > aren't?
> > > >
> > > > >
> > > > > How about this -
> > > > https://docs.mailman3.org/en/latest/install/virtualenv.html
> > > > > ??
> > > >
> > > > I'm not using a virtual environment. I'm using all native Debian 12
> > > > packages,
> > > > installed via apt. The virtual environment docs are actually even worse
> > > > (even
> > > > more confusing).
> > >
> > >
> > > Worse? :-)
> >
> > Even more confusing. Both sets of docs make various assumptions and don't
> > really explain things properly. Like everywhere where "settings.py" is
> > mentioned, it really means "/etc/mailman3/mailman-web.py"
> >
>
> No! It means /etc/mailman3/settings.py - literally!
>
>
> > In any case, the virtual environment docs are hard to relate to a "native"
> > install and are generally hard to follow, since they seem to jump all over
> > the
> > place.
>
>
> When one day you'll be able to internalize what a Python virtual
> environment is, you'll realize that it's VERY convenient.
> You will actually embrace it from that point onwards.
>
> (Spaghetti docs?) And it is hard to replace the various (and not
> > always consistent) virtual environment paths and settings files to the
> > "native"
> > paths.
>
>
> Actually, if you're this inclined to run everything natively, MM3 is
> perhaps not for you. Why? Because you'll not easily find help here.
> We focus on the virtual environment only as the standard.. Why? Because no
> one is willing to deal with ALL the OS-centric packaging
> out there. Python virtual environment is universal across all the OSes, I
> can say.
>
>
> > The "official" docs are just not useful to me, since I am not using a
> > virtual
> > environment. If a virtual environment is recomended, what is the point of
> > the
> > Debian 12 packages?
>
>
> We cannot answer that here. I guess they are meant for people like you who
> strive under pain :-)
> With the Python virtual environment, I can install and manage MM3 in almost
> any *nix OS.
>
>
> > Are they just not meant to be used? Really? Do you mean that I should use
> > a separate package management system for Mailman3? That
> > really sucks.
> >
>
> Yes, they are meant to be used. Noone denies that. However, they are not
> packaged by the Mailman Developers.
> Did you read one response from Mark Sapiro where he said, and I quote:
> ```
> If you prefer to use the Debian packages, that's fine, but if using the
> Debian packages, your primary resource for support, documentation, bug
> reports, etc. should be Debian. See https://wiki.list.org/x/12812344
> ```
> So yes, go ahead and use the Debian packages. No one is stopping you.
I uninstalled them and have given up on mm3. It means the main mailling list
I have been hosting for the past while (more than a decade), will have to
migrate to something else... :-(
>
>
--
Robert Heller -- Cell: 413-658-7953 GV: 978-633-5364
Deepwoods Software -- Custom Software Services
http://www.deepsoft.com/ -- Linux Administration Services
heller(a)deepsoft.com -- Webhosting Services
1 year, 11 months
[MM3-users] Re: How to delete non-users
by Allan Hansen
Hi Mark,
Thank you for looking into it.
We are very strict about memberships, which we are because of spam, bots and malicious contributors and because we don't want anyone to think that our lists are used for spam:
When a user applies, the server sends a message to the moderator.
The moderator communicates with the potential member and accepts or does not accept the application.
At this point, if the user has not been accepted, but tried to send a message to the list, a non-member membership is created.
When he/she logs in to list his/her account, the list to which he/she holds non-memberships will be listed and the user will think that he/she has been properly subscribed (why else are the lists listed). Noone notices the column that shows the role as 'nonmember.' So he/she thinks that the subscription request has been accepted, but nothing is working. That's why the 'non-member' record is an issue. I also don't see why non-members are automatically added, filling up the database with junk (at least from our point of view, with all respect).
But our lists don't accept messages from non-members. Such messages are quietly discarded, as most are spam, as mentioned above.
So now the user is neither getting emails from the lists nor is unable to send messages to the list.
The next step for the user is to complain to me. ☹
I have looked for a template that could be used to warn someone when he/she is added as a non-member, but did not find one. It's also not clear that I'd want one, as most of these non-subscriptions are by spammers and I prefer not to reply to spammers. __
I tried your suggestion below, Mark.
Here's my transcript:
**********
Welcome to the GNU 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.
>>> lm = getUtility(IListManager)
>>> for l in lm:
... for nm in l.nonmembers.members:
... nm.unsubscribe()
...
>>>
**********
I did this twice, once with commit() and once typing ctrl/d (ctrl/D) just gave me a beep.
Calling commit() did not return to the ... as in your example, but showed the >>> prompt, so I tried ctrl/D (beep) and then ctrl/d (exit).
I then went to the Postorius page for one of the lists and found that all the non-members were still present.
Yours,
Allan
On 9/16/22, 15:01 , "Mark Sapiro" <mark(a)msapiro.net> wrote:
On 9/16/22 11:19, Allan Hansen wrote:
> Hi all,
>
> This is a bit of an emergency:
>
> I am getting a bunch of complaints from potential list members of my lists that they can't subscribe and they don't get messages. Apparently, the issue is that they are non-members. I have never created any non-members but looking at the docs it seems that if someone sends a message to the list, they automatically become non-members.
> For individuals I have been able to delete their non-membership and they then could subscribe properly.
I don't understand. the fact that an address is a non-member of a list
should not impact subscribing that address as a member.
> I have looked at some of my most popular lists and they have hundreds of non-members! It will take me an awful amount of time to remove each one manually, and not doing it - handling each as they complain - is also a lot of waste of time and cause of frustration for all involved.
What is actually happening when the non-member attempts to subscribe as
a member? What do they do and what it the result?
> I have tried scripting it with delmember, but it does not take the '-r nonmember' option ('findmember' does!).
>
> Can anyone help me find out how to
> a. delete all non-members of all my lists
If you have access to `mailman shell` you could do:
```
$ mailman shell
Welcome to the GNU 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.
>>> lm = getUtility(IListManager)
>>> for l in lm:
... for nm in l.nonmembers.members:
... nm.unsubscribe()
...
>>> commit()
```
> b. prevent MM3 from creating new non-members in the future (so I don't have to keep removing them)
nonmembers are an integral part of Mailman 3's architecture. The basic
idea is a nonmember has a moderation action and setting a nonmembers
moderation replaces MM 2.1's adding that address to one of
*_these_nonmembers (The legacy *_these_nonmembers attributes still
exist, but only to support regexps).
It would require extensive modification to not create nonmembers.
However, I still don't understand why the presence of a nonmember record
is an issue.
--
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/
3 years, 9 months
[MM3-users] Re: Held messages not delivered after approval
by Krinetzki, Stephan
Hi Mark, Hi Stephen,
so I updated now my configuration a bit. The logging is now default:
[logging.archiver] datefmt: %b %d %H:%M:%S %Y
[logging.archiver] format: %(asctime)s (%(process)d) %(message)s
[logging.archiver] level: info
[logging.archiver] path: mailman.log
[logging.archiver] propagate: no
[logging.bounce] datefmt: %b %d %H:%M:%S %Y
[logging.bounce] format: %(asctime)s (%(process)d) %(message)s
[logging.bounce] level: info
[logging.bounce] path: bounce.log
[logging.bounce] propagate: no
[logging.config] datefmt: %b %d %H:%M:%S %Y
[logging.config] format: %(asctime)s (%(process)d) %(message)s
[logging.config] level: info
[logging.config] path: mailman.log
[logging.config] propagate: no
[logging.database] datefmt: %b %d %H:%M:%S %Y
[logging.database] format: %(asctime)s (%(process)d) %(message)s
[logging.database] level: warn
[logging.database] path: mailman.log
[logging.database] propagate: no
[logging.debug] datefmt: %b %d %H:%M:%S %Y
[logging.debug] format: %(asctime)s (%(process)d) %(message)s
[logging.debug] level: info
[logging.debug] path: debug.log
[logging.debug] propagate: no
[logging.error] datefmt: %b %d %H:%M:%S %Y
[logging.error] format: %(asctime)s (%(process)d) %(message)s
[logging.error] level: info
[logging.error] path: mailman.log
[logging.error] propagate: no
[logging.fromusenet] datefmt: %b %d %H:%M:%S %Y
[logging.fromusenet] format: %(asctime)s (%(process)d) %(message)s
[logging.fromusenet] level: info
[logging.fromusenet] path: mailman.log
[logging.fromusenet] propagate: no
[logging.gunicorn] datefmt: %b %d %H:%M:%S %Y
[logging.gunicorn] format: %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
[logging.gunicorn] level: info
[logging.gunicorn] path: mailman.log
[logging.gunicorn] propagate: no
[logging.http] datefmt: %b %d %H:%M:%S %Y
[logging.http] format: %(asctime)s (%(process)d) %(message)s
[logging.http] level: info
[logging.http] path: mailman.log
[logging.http] propagate: no
[logging.locks] datefmt: %b %d %H:%M:%S %Y
[logging.locks] format: %(asctime)s (%(process)d) %(message)s
[logging.locks] level: info
[logging.locks] path: mailman.log
[logging.locks] propagate: no
[logging.mischief] datefmt: %b %d %H:%M:%S %Y
[logging.mischief] format: %(asctime)s (%(process)d) %(message)s
[logging.mischief] level: info
[logging.mischief] path: mailman.log
[logging.mischief] propagate: no
[logging.plugins] datefmt: %b %d %H:%M:%S %Y
[logging.plugins] format: %(asctime)s (%(process)d) %(message)s
[logging.plugins] level: info
[logging.plugins] path: plugins.log
[logging.plugins] propagate: no
[logging.root] datefmt: %b %d %H:%M:%S %Y
[logging.root] format: %(asctime)s (%(process)d) %(message)s
[logging.root] level: info
[logging.root] path: mailman.log
[logging.root] propagate: no
[logging.runner] datefmt: %b %d %H:%M:%S %Y
[logging.runner] format: %(asctime)s (%(process)d) %(message)s
[logging.runner] level: info
[logging.runner] path: mailman.log
[logging.runner] propagate: no
[logging.smtp] datefmt: %b %d %H:%M:%S %Y
[logging.smtp] every: $msgid smtp to $listname for $recip recips, completed in $time seconds
[logging.smtp] failure: $msgid delivery to $recip failed with code $smtpcode, $smtpmsg
[logging.smtp] format: %(asctime)s (%(process)d) %(message)s
[logging.smtp] level: info
[logging.smtp] path: smtp.log
[logging.smtp] propagate: no
[logging.smtp] refused: $msgid post to $listname from $sender, $size bytes, $refused failures
[logging.smtp] success: $msgid post to $listname from $sender, $size bytes
[logging.subscribe] datefmt: %b %d %H:%M:%S %Y
[logging.subscribe] format: %(asctime)s (%(process)d) %(message)s
[logging.subscribe] level: info
[logging.subscribe] path: mailman.log
[logging.subscribe] propagate: no
[logging.task] datefmt: %b %d %H:%M:%S %Y
[logging.task] format: %(asctime)s (%(process)d) %(message)s
[logging.task] level: info
[logging.task] path: mailman.log
[logging.task] propagate: no
[logging.vette] datefmt: %b %d %H:%M:%S %Y
[logging.vette] format: %(asctime)s (%(process)d) %(message)s
[logging.vette] level: info
[logging.vette] path: mailman.log
[logging.vette] propagate: no
Further, I edited the logrotate:
/var/log/mailman/mailman-logs/*.log {
missingok
daily
compress
delaycompress
nomail
notifempty
rotate 14
dateext
su mailman mailman
olddir /var/log/mailman/mailman-logs/oldlogs
postrotate
/bin/kill -HUP `cat /opt/mailman/var/master.pid 2>/dev/null` 2>/dev/null || true
# Don't run "mailman3 reopen" with SELinux on here in the logrotate
# context, it will be blocked
/opt/mailman/mailman-venv/bin/mailman reopen >/dev/null 2>&1 || true
endscript
}
It is now more like the Fedora one and seems to be better.
Now in the mailman.log I see the HOLD messages and the approved messages. The smtp.log logs just the incoming Mail, which seems to be fine.
So, here a complete Trace:
smtp.log:
Aug 05 10:18:40 2025 (217984) Available AUTH mechanisms: LOGIN(builtin) PLAIN(builtin)
Aug 05 10:18:40 2025 (217984) Peer: ('127.0.0.1', 57074)
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) handling connection
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'LHLO lists.rwth-aachen.de'
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'MAIL FROM:<SENDER> SIZE=15187'
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) sender: SENDER
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'RCPT TO:<stephansmodliste(a)lists.example.com>'
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) recip: stephansmodliste(a)lists.example.com
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'DATA'
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) >> b'QUIT'
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) connection lost
Aug 05 10:18:40 2025 (217984) ('127.0.0.1', 57074) Connection lost during _handle_client()
The mailman.log:
Aug 05 10:18:40 2025 (217983) HOLD: stephansmodliste(a)lists.example.com post from SENDER held, message-id=<b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN>: The message is not from a list member
Aug 05 10:21:04 2025 (218015) held message approved, message-id: <b93e46d8342f42039c99e1d2d036c711@SENDERDOMAIN>
[05/Aug/2025:10:21:04 +0200] "POST /3.1/lists/stephansmodliste(a)lists.example.com/held/211056 HTTP/1.1" 204 0 "-" "GNU Mailman REST client v3.3.5"
[05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=0&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5"
[05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held?count=10&page=1 HTTP/1.1" 200 90 "-" "GNU Mailman REST client v3.3.5"
[05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/requests/count?token_owner=moderator HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5"
[05/Aug/2025:10:21:04 +0200] "GET /3.1/lists/stephansmodliste(a)lists.example.com/held/count HTTP/1.1" 200 73 "-" "GNU Mailman REST client v3.3.5"
Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25
The last error is a very often in the mailman.log:
Aug 05 09:46:12 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:46:13 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 09:46:13 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 09:46:14 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 09:46:24 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 09:50:22 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 09:50:24 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:53:30 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 09:55:01 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 09:55:01 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:55:09 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 09:57:44 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 09:57:46 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:50 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:52 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:52 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:53 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:53 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 09:58:53 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:01:18 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:02:02 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 10:07:11 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 10:10:36 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:11:35 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:16:04 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:16:05 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:16:07 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:16:58 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:17:42 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:18:30 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:20:13 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:21:05 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:08 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:08 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:31 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:37 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:44 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:47 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:50 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:28:57 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:29:22 2025 (217988) Cannot connect to SMTP server localhost on port 25
Aug 05 10:29:40 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:29:41 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:30:37 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:30:37 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:30:50 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:31:15 2025 (217987) Cannot connect to SMTP server localhost on port 25
Aug 05 10:33:42 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:33:53 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:34:27 2025 (217985) Cannot connect to SMTP server localhost on port 25
Aug 05 10:34:28 2025 (217986) Cannot connect to SMTP server localhost on port 25
Aug 05 10:38:25 2025 (230250) Cannot connect to SMTP server lists.example.com on port 25
Aug 05 10:38:25 2025 (230247) Cannot connect to SMTP server lists.example.com on port 25
Even after changing the smtp_host in mailman.cfg this error appears randomly.
Sadly the mail does not get delivered.
--
Stephan Krinetzki
IT Center
Gruppe: Anwendungsbetrieb und Cloud
Abteilung: Systeme und Betrieb
RWTH Aachen University
Seffenter Weg 23
52074 Aachen
Tel: +49 241 80-24866
Fax: +49 241 80-22134
krinetzki(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Social Media Kanäle des IT Centers:
https://blog.rwth-aachen.de/itc/
https://www.facebook.com/itcenterrwth
https://www.linkedin.com/company/itcenterrwth
https://twitter.com/ITCenterRWTH
https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ
-----Original Message-----
From: Mark Sapiro <mark(a)msapiro.net>
Sent: Tuesday, August 5, 2025 12:51 AM
To: mailman-users(a)mailman3.org
Subject: [MM3-users] Re: Held messages not delivered after approval
On 8/4/25 00:21, Krinetzki, Stephan wrote:
>>
>> And for every one of those shunted messages there should be an exception with traceback logged in mailman.log. Those tracebacks should be helpful.
>
> If there were any. Maybe the "debug" level should be "info". But for which logs?
The standard logging levels from lowest to highest are
debug
info
warning
error
critical
Whatever level is set for a log results in all messages of that level or higher being logged. I.e. if the log's level is debug, all messages for that log of any level should be logged.
For every shunted message, a message like
`SHUNTING: <file name without the .pck extention>` preceded by the exception and traceback is logged to error.log with level error. See
https://gitlab.com/mailman/mailman/-/blob/master/src/mailman/core/runner.py…
> Maybe the restart at night after the lograte maybe the issue.
As I said before, blindly restarting Mailman is a bad idea. On servers that I maintain, I always verify that all queues are empty before stopping or restarting Mailman. If necessary, I'll kill the incoming runner and wait for the out queue to empty and then stop mailman. If you want to do this daily, you could automate that., e.g.
```
if queues empty:
restart Mailman
else:
when in queue is empty, sigterm incoming runner
when out queue is empty, stop Mailman
when Mailman stopped, start Mailman ``` The stop/start is needed because a simple restart at that point won't start the sigtermed incoming runner.
--
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/
Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
This message sent to krinetzki(a)itc.rwth-aachen.de
10 months, 2 weeks
[MM3-users] Re: messages stuck in the bad queue
by Ken Alker
--On Sunday, June 25, 2023 2:47 PM -0700 Mark Sapiro <mark(a)msapiro.net>
wrote:
> On 6/25/23 1:31 PM, Ken Alker wrote:
>>
>> I moved the .psv file from the bad queue into the shunt queue. I then
>> ran "mailman unshunt" (as user 'mailman' while in the virtual
>> environment). I tailed mailman.log during this process and no logs
>> were spit out. The date stamp on the .psv file never changed (maybe
>> it does not when being moved between queues?) and, AFAICT, the file
>> never moved from the shunt queue. I waited maybe five minutes, tops.
>
>
> I forgot that the extension in the `bad` queue is `.psv` (for preserve).
> You have to rename it to `.pck`.
Ah! I noticed the file extension difference but only for a fleeting
moment, and I convinced myself during that moment that I must have looked
at the original one (.pck) incorrectly (even though I knew it stood for
"pickle"... and so the vaguely-noted discrepancy never made it to the stop
of the stack... but it eventually may have, but I still wouldn't have know
how that would affect the queued file. That solves that issue.
>>>> Is there a way to reprocess the bad queue?
>>>
>>> You could just move the messages to the 'in' queue.
>
>
> Changing .psv to .pck in the process. this can be done, e.g., by
> ```
> for file in `ls var/queue/bad/*.psv;do mv /var/queue/bad/$file
> /var/queue/in/${file/psv/pck};done
> ```
I moved one message by hand, and, wow.. the runner just gobbles it up...
fast!
>> I just now tried moving the same message into the 'in' queue but, again,
>> nothing happened. I left it in there for five minutes. Do I have to
>> run a program to get it to act on the 'in' queue (I presume that there
>> is a "runner" that is always looking and taking care of this already as
>> I presume this is the queue where all 'normal' traffic is handled).
>
>
> Again, you need to change the extension to .pck.
>
>
>> Here are the (obfusacted) results of "mailman qfile
>> /opt/mailman/mm/var/queue/shunt/1675389793.6945386+2aeaf0015558c9d8380c9
>> 6142c3fa9d03a8142bc.psv" (the message I was experimenting with):
>>
>> [----- start pickle -----]
>> <----- start object 1 ----->
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset="us-ascii"
>> Content-Transfer-Encoding: 7bit
>> Subject: THE-list subscription notification
>> From: email(a)obfuscated.com
>> To: the-list-owner(a)lists.obfuscated.com
>> Message-ID: <167538979369.2390432.521344217673230839(a)obfuscated.net>
>> Date: Thu, 02 Feb 2023 18:03:13 -0800
>> Precedence: bulk
>>
>> user(a)domain.tld has been successfully subscribed to THE-list.
>>
>> <----- start object 2 ----->
>> { '_parsemsg': False,
>> 'envsender': 'email(a)obfuscated.com',
>> 'listid': 'the-list.obfusacted.com',
>> 'nodecorate': True,
>> 'recipients': {'person(a)domain.tld'},
>> 'reduced_list_headers': True,
>> 'version': 3}
>> [----- end pickle -----]
>
>
> I was assuming these were list welcome messages which they aren't. They
> are owner notifications, so they were sent to the -owner address and
> processed through the owner-pipeline, but unless the Debian package
> changed the default-owner-pipeline, it doesn't contain mime-delete so how
> they ended up in the `bad` queue is still a mystery.
>
> However, what would be the point of resending these at this time?
Because I didn't know if they were ALL subscribe notices or if there were
other people's emails mixed in. I felt, at the time, that it would be
easier to requeue them and then be able to manipulate the results in my
email client (ie. sort by subject) than to try to do it at the Unix level.
That said, since there is more than one queue I'd have to move them into,
the sorting process would require manipulating/viewing the messages at the
Unix level first anyway and if I have to do that I might as well just
inspect them all at the Unix level and skip the re-injection, as you noted.
Also, after countless hours of learning over the past two days, I'm more
qualified to do that now.
So, I modified your suggested script thusly:
for file in `ls var/queue/bad/*.psv`
do
mailman qfile $file >>results
done
and then compared the number of times "subscription notification" appeared
in the results file (grep subscription\ notification results | wc) to the
total numbers of "bad" messages (ls var/queue/bad | wc) and they matched
(1142 of each). And just for fun and as a second check, I did a "grep
subscription results | sort | uniq" and ended up with three lines of
output; one for each mailing list import, and nothing more. It's things
like that that really make me appreciate and enjoy the Unix shell.
Thanks for the wisdom and for a slice of your time; I'm learning a lot and
I appreciate the help.
Ken Alker
KA6KEN
2 years, 11 months
[MM3-users] Re: Please help - Held message is crashing mailman.
by Alex King
Thanks for your help Mark, it's ideal having the pointer to the issue in
gitlab.
I'll raise a bug with Ubuntu because this makes mailman3 in their LTS
version unusable for me. Perhaps they can backport a fix for their
version in LTS, otherwise they may have a backport or PPA source where I
can get a 3.2 version, or just pin some packages from cosmic or disco.
I think documenting this will be useful to people who hit the issue in
future (Bionic/18.04 is supported until 2023, and likely the most used
until 20.04 is released).
Thanks,
Alex
On 7/04/19 4:29 AM, Mark Sapiro wrote:
> On 4/5/19 10:27 PM, Alex King via Mailman-users wrote:
>> Hi,
>>
>> I've used mailman a lot in the past, and decided to install mailman3 in
>> a recent install. I'm unimpressed so far, it seems buggy.
>>
>> Running on Ubuntu 18.04.2 LTS from packages, mailman3 3.1.1-9,
>> mailman3-web 0+20170523-14, python-django-postorius 1.1.2-3.
>>
>> After a few messages, I now can't go to the "Held Messages" in
>> postorius, I get a 500 error.
>>
>> I tried to interact on the command line, but could not work out how.
>> Reading
>> https://mailman.readthedocs.io/en/latest/src/mailman/docs/install.html
>> and
>> https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…,
>> I tried:
>>
>> # mailman shell
>> Welcome to the GNU Mailman shell
>>
>>>>> command = cli('mailman.commands.cli_withlist.shell')
>> Traceback (most recent call last):
>> File "/usr/lib/python3.6/code.py", line 91, in runcode
>> exec(code, self.locals)
>> File "<console>", line 1, in <module>
>> NameError: name 'cli' is not defined
>>
>> I did a lot of reading of the manual and googled, but I have no idea
>> where the cli object is supposed to come from.....? The documentation
>> is confusing.
>
> The line
>
> command = cli('mailman.commands.cli_withlist.shell')
>
> in
> <https://mailman.readthedocs.io/en/latest/src/mailman/commands/docs/shell.ht…>
> is dependent upon some behind the scenes setup to make the doctests
> work. Granted this is confusing, but basically all that does is set
> things up for the doctests to run the 'mailman shell' command. It is not
> intended to be run from within 'mailman shell'.
>
>
>> Anyway, after some trial and error, i found:
>>
>> # mailman shell
>> Welcome to the GNU Mailman shell
>>>>> list_manager = getUtility(IListManager)
>>>>> m=list_manager.get("committee(a)[redacted].org")
>>>>> from mailman.interfaces.requests import IListRequests
>>>>> requests = IListRequests(m)
>>>>> [x for x in requests.held_requests][0].id
>> 8
>>>>> requests.get_request(8)
>> Traceback (most recent call last):
>> File "/usr/lib/python3.6/code.py", line 91, in runcode
>> exec(code, self.locals)
>> File "<console>", line 1, in <module>
>> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py",
>> line 85, in wrapper
>> return function(args[0], config.db.store, *args[1:], **kws)
>> File "/usr/lib/python3/dist-packages/mailman/model/requests.py", line
>> 120, in get_request
>> result.data_hash, expunge=False)
>> File "/usr/lib/python3/dist-packages/mailman/database/transaction.py",
>> line 85, in wrapper
>> return function(args[0], config.db.store, *args[1:], **kws)
>> File "/usr/lib/python3/dist-packages/mailman/model/pending.py", line
>> 138, in confirm
>> value = json.loads(keyvalue.value)
>> File "/usr/lib/python3.6/json/__init__.py", line 354, in loads
>> return _default_decoder.decode(s)
>> File "/usr/lib/python3.6/json/decoder.py", line 339, in decode
>> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
>> File "/usr/lib/python3.6/json/decoder.py", line 355, in raw_decode
>> obj, end = self.scan_once(s, idx)
>> json.decoder.JSONDecodeError: Unterminated string starting at: line 1
>> column 1 (char 0)
>>
>> It seems something was written out to disk that can't be read in for
>> some reason (assuming a json object on disk?)
>
> This is <https://gitlab.com/mailman/mailman/issues/385> which should be
> fixed by <https://gitlab.com/mailman/mailman/merge_requests/333>. The
> fix in in Mailman core version 3.2.0
>
>
>> How do I debug this further? How do I find the json being decoded? Any
>> help would be appreciated. (I found mailman2 just worked, I was happy
>> with that.)
>
> The issue is in storing a pickled representation of the json encoding of
> 'rule_misses'. This gets very long if you have lots of header filters,
> and with at least the mysql backend gets truncated in the database which
> causes the Unterminated string error.
>
> I'm not sure what your options are for upgrading. The current Debian
> packages are all >= 3.2.0 [1], but Ubuntu doesn't get 3.2.0 until cosmic
> (18.10) [2].
>
> [1] https://packages.debian.org/search?keywords=mailman3
> [2] https://packages.ubuntu.com/search?keywords=mailman3
>
>> (My colleague posted a bug about this I believe but I don't have the
>> link to that.)
>
> I haven't seen it.
>
>
7 years, 2 months
[MM3-users] Re: error changed after restart
by Guillermo Hernandez (Oldno7)
On 6/2/21 18:08, Abhilash Raj wrote:
>
> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>> I restarted de server and the error changed. Now the log shows
>> "KeyError: 'subscription_mode'":
> Did you also restart Mailman Core after the upgrade?
Yes, indeed:
I stopped mailman core and all the processes related. Did the upgrades.
Started all again. Find the errors in the web user interface. Stopped
all again. Looked for errors in the log. Restarted the complete server.
Found the second error that this second mail is about to. It happens
when, in the main page that shows all the lists you click to see one of
them. It seems to me that it has been database structure changes in
django that the upgrade is not aware... but it's a very long shot from
my side.
I'm using sqlite as django database and mysql for mailman.
>
>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal Server
>> Error: /mailman3/mailman3/lists/name_and_domain.of.the.list
>> Traceback (most recent call last):
>> File
>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>> line 119, in __getattr__
>> return self._get(name)
>> File
>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>> line 86, in _get
>> raise KeyError(key)
>> KeyError: 'subscription_mode'
>>
>> During handling of the above exception, another exception occurred:
>>
>> Traceback (most recent call last):
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py",
>> line 34, in inner
>> response = get_response(request)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>> line 115, in _get_response
>> response = self.process_exception_by_middleware(e, request)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>> line 113, in _get_response
>> response = wrapped_callback(request, *callback_args, **callback_kwargs)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>> line 71, in view
>> return self.dispatch(request, *args, **kwargs)
>> File
>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py",
>> line 74, in dispatch
>> return super(MailingListView, self).dispatch(request, *args, **kwargs)
>> File
>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>> line 97, in dispatch
>> return handler(request, *args, **kwargs)
>> File
>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py", line
>> 295, in get
>> member.subscription_mode ==
>> File
>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>> line 124, in __getattr__
>> self.__class__.__name__, name))
>> AttributeError: 'Member' object has no attribute 'subscription_mode'
>> ***********************
>> some info about the installed versions via pip list:
>> pip list | grep django
>> django-allauth 0.44.0
>> django-appconf 1.0.4
>> django-compressor 2.4
>> django-extensions 3.1.0
>> django-gravatar2 1.4.4
>> django-haystack 3.0
>> django-mailman3 1.3.5
>> django-picklefield 3.0.1
>> django-q 1.3.4
>> djangorestframework 3.12.2
>>
>> pip list | grep mailman
>> django-mailman3 1.3.5
>> mailman 3.3.3
>> mailman-hyperkitty 1.1.0
>> mailmanclient 3.3.2
>>
>> pip list | grep postorius
>> postorius 1.3.4
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 6/2/21 11:12, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>>> I've just upgrade mailman 3 installation following Mr. Sapiro advice:
>>> did a
>>>
>>> pip install --upgrade django-mailman3 hyperkitty mailman mailmanclient
>>> mailman-hyperkitty postorius
>>>
>>> I did a "python3 manage.py migrate" after, too.
>>>
>>> And all seemed to run well.
>>>
>>> All the lists showed in postorius via web, but when I try to accesss
>>> into one of them the browser shows an error.
>>>
>>> In the log you can see:
>>>
>>> *-*-*-*-*-*-*
>>>
>>> Traceback (most recent call last):
>>> File
>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>> line 119, in __getattr__
>>> return self._get(name)
>>> File
>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>> line 86, in _get
>>> raise KeyError(key)
>>> KeyError: 'get_requests_count'
>>>
>>> ... (And after all the traceback lines)
>>>
>>> AttributeError: 'MailingList' object has no attribute
>>> 'get_requests_count'
>>>
>>> *-*-*-*-*-*-*-*
>>>
>>> The lists seem to be distributing messeages well.. but I cannot acces
>>> via web administration (django/postorius)
>>>
>>> Can anyone point me in the right direction to solve this, please?
>>>
>>> _______________________________________________
>>> 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/
>>>
>> _______________________________________________
>> 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/
>>
5 years, 4 months
[MM3-users] Re: Message-Footer after migrating to Mailman3
by christopher.claus＠tgcamberg1848.de
Mark Sapiro wrote:
> > ERROR 2021-05-24 16:22:22,895 1648 django.security.DisallowedHost Invalid HTTP_HOST header: 'tgc_mailman_web:8000'. The domain name provided is not valid according to RFC 1034/1035.
> > WARNING 2021-05-24 16:22:22,896 1648 django.request Bad Request: /postorius/api/templates/list/homepage.gruppe.tgcamberg1848.de/list:member:regular:footer
> > It appears you created the new template with Postorius, but there is an
> issue for Postorius templates. Possibly your Django setting for
> POSTORIUS_TEMPLATE_BASE_URL needs to be adjusted.
> > Obviously I have a problem with the hostname. I set
> > [code]
> > POSTORIUS_TEMPLATE_BASE_URL=http://tgc_mailman_web:8000
> > [/code]
> > where tgc_mailman_web is my container name. This URL ist stored in the DB-table "template" for the name=list:member:regular:footer. A call to my fqdn or to localhost
> > [code]
> > wget http://localhost:8000/postorius/api/templates/list/homepage.gruppe.tgcamberg...
> > [/code]
> > will return the footer itself - this works fine. Therefore, should i set POSTORIUS_TEMPLATE_BASE_URL to http://localhost:8000?
> > If that works, yes.
Hi Mark,
thanks for your reply and excuse my delay. I was very busy in the last weeks but made some tests. Newly created templates with POSTORIUS_TEMPLATE_BASE_URL=http://localhost:8000 did not work. I changed it to my fqdn - at the moment I am able to access the template via this URl (e.G. http://lists.example.de:8000/postorius/api/templates/list/homepage.lists.ex…)
But if I try to send an email I got the following error:
Jul 09 16:00:37 2021 (27) Uncaught runner exception: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/homepage.lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused'))
Jul 09 16:00:37 2021 (27) Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn
conn = connection.create_connection(
File "/usr/lib/python3.8/site-packages/urllib3/util/connection.py", line 84, in create_connection
raise err
File "/usr/lib/python3.8/site-packages/urllib3/util/connection.py", line 74, in create_connection
sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen
httplib_response = self._make_request(
File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 392, in _make_request
conn.request(method, url, **httplib_request_kw)
File "/usr/lib/python3.8/http/client.py", line 1255, in request
self._send_request(method, url, body, headers, encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1301, in _send_request
self.endheaders(body, encode_chunked=encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1250, in endheaders
self._send_output(message_body, encode_chunked=encode_chunked)
File "/usr/lib/python3.8/http/client.py", line 1010, in _send_output
self.send(msg)
File "/usr/lib/python3.8/http/client.py", line 950, in send
self.connect()
File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 187, in connect
conn = self._new_conn()
File "/usr/lib/python3.8/site-packages/urllib3/connection.py", line 171, in _new_conn
raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
resp = conn.urlopen(
File "/usr/lib/python3.8/site-packages/urllib3/connectionpool.py", line 724, in urlopen
retries = retries.increment(
File "/usr/lib/python3.8/site-packages/urllib3/util/retry.py", line 439, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 173, in _one_iteration
self._process_one_file(msg, msgdata)
File "/usr/lib/python3.8/site-packages/mailman/core/runner.py", line 266, in _process_one_file
keepqueued = self._dispose(mlist, msg, msgdata)
File "/usr/lib/python3.8/site-packages/mailman/runners/incoming.py", line 79, in _dispose
process(mlist, msg, msgdata, start_chain)
File "/usr/lib/python3.8/site-packages/mailman/core/chains.py", line 79, in process
link.function(mlist, msg, msgdata)
File "/usr/lib/python3.8/site-packages/mailman/chains/hold.py", line 232, in _process
template = getUtility(ITemplateLoader).get(
File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 188, in get
contents = getUtility(ITemplateManager).get(
File "/usr/lib/python3.8/site-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3.8/site-packages/mailman/model/template.py", line 110, in get
contents = protocols.get(actual_uri, **auth)
File "/usr/lib/python3.8/site-packages/mailman/utilities/protocols.py", line 38, in get
response = requests.get(url, timeout=REQUEST_TIMEOUT, **kws)
File "/usr/lib/python3.8/site-packages/requests/api.py", line 76, in get
return request('get', url, params=params, **kwargs)
File "/usr/lib/python3.8/site-packages/requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 530, in request
resp = self.send(prep, **send_kwargs)
File "/usr/lib/python3.8/site-packages/requests/sessions.py", line 643, in send
r = adapter.send(request, **kwargs)
File "/usr/lib/python3.8/site-packages/requests/adapters.py", line 516, in send
raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='lists.example.de', port=8000): Max retries exceeded with url: /postorius/api/templates/list/lists.example.de/list:admin:action:post (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7fe80eaaec40>: Failed to establish a new connection: [Errno 111] Connection refused'))
I set POSTORIUS_TEMPLATE_BASE_URL=lists.example.de:8000 and I have no idea, why the connection is refused. Do you see any configuration error d or have another idea?
Best regards,
chrclaus
4 years, 11 months
[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'
by Odhiambo Washington
On Sat, 25 Jul 2020 at 19:58, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 7/25/20 6:36 AM, Odhiambo Washington wrote:
> > I decided to try this again, on FreeBSD-12.1
> >
> > I still decided to follow
> > https://wiki.list.org/DOC/Mailman%203%20installation%20experience which
> I
> > know is not the main documentation, but I find the process easier to
> follow.
> > I am also taking notes to see if I could share if I manage to succeed.
> This
> > is important for me because Python-2.7 is being removed from FreeBSD in
> Dec
> > 2020. I need to bail
> > out of mailman-2.x before that happens so I am trying my hand again om
> MM3.
> > I have failed before :-)
>
> Even if it's not in FreeBSD, you can download Python 2.1.18 from
> <https://www.python.org/downloads/release/python-2718/> and install it.
>
>
> > (venv) [root@gw /opt/mailman/mm]# pip install flufl.lock
> ...
> > Even after the 'pip install flufl.lock' it still doesn't find it!
>
>
> This is a packaging glitch with the flufl modules. Remove and reinstall
> them.
>
> pip uninstall flufl.bounce flufl.i18n flufl.lock
> pip install flufl.bounce flufl.i18n flufl.lock
>
>
It would appear that luck isn't just on my side:
root@gw:/opt/mailman/mm # pip uninstall flufl.bounce flufl.i18n flufl.lock
WARNING: Skipping flufl.bounce as it is not installed.
WARNING: Skipping flufl.i18n as it is not installed.
Found existing installation: flufl.lock 4.0
Uninstalling flufl.lock-4.0:
Would remove:
/usr/local/lib/python3.7/site-packages/flufl.lock-4.0-py3.7-nspkg.pth
/usr/local/lib/python3.7/site-packages/flufl.lock-4.0.dist-info/*
/usr/local/lib/python3.7/site-packages/flufl/lock/*
Proceed (y/n)? y
Successfully uninstalled flufl.lock-4.0
root@gw:/opt/mailman/mm # pip install flufl.bounce flufl.i18n flufl.lock
Collecting flufl.bounce
Downloading flufl.bounce-3.0.1-py3-none-any.whl (175 kB)
|████████████████████████████████| 175 kB 18 kB/s
Collecting flufl.i18n
Downloading flufl.i18n-3.0.tar.gz (21 kB)
Processing
/root/.cache/pip/wheels/5a/de/bb/5e6448d5923f53f07f181ec225bf7b1d778d42384869dcf261/flufl.lock-4.0-py3-none-any.whl
Requirement already satisfied: atpublic in
/usr/local/lib/python3.7/site-packages (from flufl.bounce) (1.0)
Collecting zope.interface
Downloading zope.interface-5.1.0.tar.gz (225 kB)
|████████████████████████████████| 225 kB 35 kB/s
Requirement already satisfied: psutil in
/usr/local/lib/python3.7/site-packages (from flufl.lock) (5.7.2)
Requirement already satisfied: setuptools in
/usr/local/lib/python3.7/site-packages (from zope.interface->flufl.bounce)
(40.6.2)
Building wheels for collected packages: flufl.i18n, zope.interface
Building wheel for flufl.i18n (setup.py) ... done
Created wheel for flufl.i18n: filename=flufl.i18n-3.0-py3-none-any.whl
size=27279
sha256=7adc834e27423865de03bcad268b86d9df1d24c59110c7e4d4b8bb5863fb4e53
Stored in directory:
/root/.cache/pip/wheels/5c/85/09/5b346688f1283d8622ac06adf4f2682bb13d36c2f410c52eb6
Building wheel for zope.interface (setup.py) ... done
Created wheel for zope.interface:
filename=zope.interface-5.1.0-cp37-cp37m-freebsd_12_1_RELEASE_p7_amd64.whl
size=194660
sha256=51f326627a9121d8b4df989714bdcdf516f02d55f99de38bb9d7cc9867d93146
Stored in directory:
/root/.cache/pip/wheels/84/93/fd/6bcb85b4bbf697c15b066350384cf3651feb47dcd5029a0b8d
Successfully built flufl.i18n zope.interface
Installing collected packages: zope.interface, flufl.bounce, flufl.i18n,
flufl.lock
Successfully installed flufl.bounce-3.0.1 flufl.i18n-3.0 flufl.lock-4.0
zope.interface-5.1.0
root@gw:/usr/home/wash # cd /opt/mailman/mm/
root@gw:/opt/mailman/mm # virtualenv venv
created virtual environment CPython3.7.8.final.0-64 in 285ms
creator CPython3Posix(dest=/opt/mailman/mm/venv, clear=False,
global=False)
seeder FromAppData(download=False, pip=bundle, setuptools=bundle,
wheel=bundle, via=copy, app_data_dir=/root/.local/share/virtualenv)
added seed packages: PyMySQL==0.10.0, Whoosh==2.7.4, gunicorn==20.0.4,
mod_wsgi==4.7.1, mysqlclient==2.0.1, pip==20.1.1, psycopg2_binary==2.8.5,
pylibmc==1.6.1, setuptools==49.2.0, wheel==0.34.2
activators
BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
root@gw:/opt/mailman/mm # bash
[root@gw /opt/mailman/mm]# source /opt/mailman/mm/venv/bin/activate
(venv) [root@gw /opt/mailman/mm]# /opt/mailman/mm/bin/mailman-post-update
+ '[' False == False ']'
+ mkdir -p /opt/mailman/mm/static
+ /opt/mailman/mm/bin/django-admin collectstatic --clear --noinput
--verbosity 0
Traceback (most recent call last):
File "/opt/mailman/mm/venv/bin/django-admin", line 33, in <module>
sys.exit(load_entry_point('Django==3.0.8', 'console_scripts',
'django-admin')())
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/core/management/__init__.py",
line 401, in execute_from_command_line
utility.execute()
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/core/management/__init__.py",
line 377, in execute
django.setup()
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/__init__.py",
line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/apps/registry.py",
line 114, in populate
app_config.import_models()
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/apps/config.py",
line 211, in import_models
self.models_module = import_module(models_module_name)
File "/usr/local/lib/python3.7/importlib/__init__.py", line 127, in
import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1006, in _gcd_import
File "<frozen importlib._bootstrap>", line 983, in _find_and_load
File "<frozen importlib._bootstrap>", line 967, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 677, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 728, in exec_module
File "<frozen importlib._bootstrap>", line 219, in
_call_with_frames_removed
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/__init__.py",
line 26, in <module>
from .email import Attachment, Email
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/email.py",
line 35, in <module>
from .mailinglist import MailingList
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/models/mailinglist.py",
line 37, in <module>
from hyperkitty.lib.utils import pgsql_disable_indexscan
File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/HyperKitty-1.3.4-py3.7.egg/hyperkitty/lib/utils.py",
line 42, in <module>
from flufl.lock import Lock
ModuleNotFoundError: No module named 'flufl.lock'
(venv) [root@gw /opt/mailman/mm]#
What else should I try?
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
5 years, 10 months
[MM3-users] Re: Timeouts
by Abhilash Raj
> On Apr 25, 2021, at 7:06 PM, tlhackque via Mailman-users <mailman-users(a)mailman3.org> wrote:
>
> On 25-Apr-21 20:34, Mark Sapiro wrote:
>> On 4/25/21 4:37 PM, tlhackque via Mailman-users wrote:
>>
>>> The described timeouts are something that hyperkitty ought to be able to
>>> avoid. For apache, the timeout is idle time between blocks of output.
>>> Hyperkitty can avoid this by generating the archive in segments (based
>>> on size, or elapsed time), flushing its output buffer, generating a
>>> multi-file archive, and/or using Transfer-Encoding: chunked (chunked
>>> doesn't work for http/2). It ought to be able to break the
> work into
>>> blocks of "n" messages & do something to generate output. Besides
>>> avoiding timeouts, working in segments allows the GUI to display
>>> meaningful progress (e.g. if you're loading with XMLHttpRequest,
>>> "onprogress") It really oughtn't be up to the user to break up the
>>> request.
>> It is not the web server that times out. I'm not sure about uwsgi
>> because I don't use it, but the timeouts I see are on servers that use
>> gunicorn as the WSGI interface to Django and the timeout is in a
>> gunicorn worker. This is controlled by the timeout setting in the
>> gunicorn config. <https://docs.gunicorn.org/en/stable/settings.html#timeout>
>>
>> Note that even 300 seconds is not enough to download the entire
>> <https://mail.python.org/archives/list/python-dev@python.org/> archive.
>>
>> It may be possible to get HyperKitty to chunk the output to avoid this,
>> but it doesn't currently do that. Care to submit an MR?
>>
>>
> I'm afraid (u)WSGI, Django, and gunicorn are not technologies that I
> work with.
>
> It sounds as if hyperkitty is compiling the entire archive before
> sending the first byte.
>
> The gunicorn doc that you pointed to says
>
> Workers silent for more than this many seconds are killed and restarted.
> Setting it to 0 has the effect of infinite timeouts by disabling
> timeouts for all workers entirely.
>
> "Silent" sounds like the standard webserver "you have to push some bits,
> or we assume you're stuck".
>
> My understanding is that gunicorn is a Python persistence server that is
> run behind a webserver proxy. So the (proxy) webserver (apache, nginx,
> ...) timeouts also apply and would need to be increased.
>
> Might be interesting to try 0 (gunicorn) / 1200 (webserver) with your
> python-dev archive, time it and see how much (encoded) data is
> transferred... (I would expect most mailing list archives to compress
> nicely, though those with binary attachments wont.)
For uwsgi, I think the parameter is called `harakiri`[1][2] (I don’t know why such a name though).
[1]: https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri
[2]: https://uwsgi-docs.readthedocs.io/en/latest/Glossary.html
> if request takes longer than specified harakiri time (in seconds), the request will be dropped and the corresponding worker recycled.
This should be set to a long enough value that allows downloading the archive.
If you are using http socket, then you want http-timeout.
Also, to set the timeout in webserver (nginx)
location / {
uwsgi_read_timeout 120s;
uwsgi_send_timeout 120s;
uwsgi_pass 0.0.0.0:8000;
include uwsgi_params;
}
Or some other value that you want.
> But fiddling with timeouts is treating the symptom, not the root cause.
> The right solution is to stream, segment (or chunk) the output, because
> in the general case, no timeout is long enough. It'll always be
> possible to find an archive that's just one byte (or second) longer than
> any chosen timeout. (See the halting problem.) You want
> the timeout
> to catch a lack of progress, not total time that's a function of
> transaction size. (Webservers may also have limits on transaction size
> - e.g. mod_security, but they're only useful when the upper bound on a
> response is knowable.) Thus, the timeout(s) should be roughly
> independent of the archive size; on the order of time-to-first-byte
> (which ordinarily is longer than time between segments/chunks).
>
> Also note that streaming requires fewer server resources than compiling
> a complete archive before sending, since you don't need to create the
> entire archive in memory (or in a tempfile). You only need enough
> memory to efficiently buffer the file I/O and to contain the compression
> tables/output buffer. Except for trivial cases, this will be
> independent of the archive size. The only downside is that if the comm
> link is slow, you may hold a reader lock on the source data for longer
> than necessary with the current scheme.
>
> Seems as though this deserves an issue. I guess I could open one - but
> you have the experience/test cases.
Hyperkitty doesn’t actually create an archive in memory or in a temp file. It uses streaming response with on the fly compression to read from database and relay to the client for download.
https://gitlab.com/mailman/hyperkitty/-/blob/master/hyperkitty/views/mlist.…
The problem could be that uwsgi seems to kill an ongoing downloading process, not an idle one for some reason. And, it seems that it is a known and intentional behavior. I don’t see a good way to disable it completely, but perhaps it can be set to a long enough value that it never essentially kills a running worker which is moving bits.
--
thanks,
Abhilash Raj (maxking)
5 years, 1 month