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
_______________________________________________
Mailman-users mailing list -- mailman-users@mailman3.org
To unsubscribe send an email to mailman-users-le...@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/42BEJFXOZ6GD6N574UQGDYDQJVXRLS3I/
This message sent to arch...@mail-archive.com
