Hi Stephen,
thanks for the comprehensive explanations and sorry for initially not answering to the list (I expected this to be the default behaviour).
Afterall it turned out that my mailman.db was somehow broken, even though I couldn't find any fishy / strange things in Postorius.
Since anyhow just a few lists are hosted on the server and subscriptions for most of them being managed fron another program, I decided to remove MM3 completely and start with a fresh configuration.
BR Andreas
Am 28.05.2025 um 18:16 schrieb Stephen J. Turnbull:
Hi Andreas
Andreas Kemper writes:
thanks for the quick response.
Please reply to list (personal mail doesn't get read any faster) or to all (I don't mind getting the duplicate). The odds are quite good that somebody else will be able to reply before I do (I live in Japan, normally I wouldn't be up now ;-).
Agree there, even though I haven't found any "settings.py" file in my Debian 12 installation yet.
Normally the override settings.py is in /etc/mailman3/settings.py. If you have no overrides, I don't know where Debian would put it. There are actually several in the distribution where the highest levels are normally in site-packages/mailman_web/settings/*.py (*not* named "settings.py", I think they are "base.py" and "mailman.py"). Come to think of it, I'm not sure whether Debian would put mailman and mailman_web in site-packages or somewhere else. :-( (I'm a Debian user since 1997, but my mission-critical applications are installed from source.)
Hmm, executing
sudo -u list mailman stop followed by sudo -u list mailman start
first deletes and afterwards recreates the lock files,
That is the expected behavior if Mailman is running normally. Are you sure there's actually a recurring problem? Or did Mailman just crash once, and the problem was the stale master lockfile?
where both of them are dated in the future,
Also expected. I forget exactly what expiration of the lock file triggers, but there's some regularly scheduled cleanup that happens then.
plus mailman.log has a duplicate line in the end,
It's a duplicate because the default is for there to be two processes serving the REST API. This is configurable. See more comments at the end.
even though I couldn't seen any mailman-related process (ps auxw | grep mailman) after stopping it.
If the process is named by the full path to the executable, then you will see "mailman", but if I recall correctly on Debian the Mailman processes run under the users "list" for Mailman core, and "www-data" for the web UIs. The various components run under different names: master, nntp, lmtp, command, rest, etc. I forget what process names you would see for the Django processes.
In doubt I will simply redirect the specific paths, mainly /accounts/fedora,
That makes sense as the earlier you reject a connection the less resources are used by your server, and the less information can leak to an attacker.
small addition to my previous post. "ps auxw" shows in total three process for MM's rest component, i. e.
python3 /usr/lib/mailman3/bin/runner -C /etc/mailman3/mailman.cfg --runner=rest:0:1
To serve ports 8000 and 8001, I would have expected two processes, but to see three of them surprises me somewhat.
It's not uncommon for moderators to go AWOL, or for somebody to spam the server with either posts or subscription activity, and end up with hundreds or thousands of entries in the pending requests table. Serving those queries can take a long timemany seconds or even time out. Mailman core deals with it in the least complex, most robust way imaginable: it runs more REST API server processes. (3 total by default. One is the "master" that handles requests from the Django apps and communication with Mailman core and starts new workers when old ones exit or crash. Two are "workers" that actually handle a certain number of requests then exit.) By default Mailman is configured to use up to four when really busy, but normally there are only two.
Django runs only one -- it deals with concurrent requests in a different way.
Steve