Eric Broens via Mailman-users writes:

 > Mainly "GET /3.1/lists/<mailing_list>@<domain>/requests HTTP/1.1"
 > takes a long time.

The only thing I can think of is that something weird is happening
with requests (held messages) on those lists.  The runner is waiting
on the database server, and eventually timing out, I think.

I believe you will find the corresponding messages under
$var_dir/messages (var_dir is usually set in mailman.cfg, if not I
believe it defaults to /usr/local/mailman3/var).  Unfortunately I
don't know how to link those entries to the messages in that directory
tree.  You can "grep -ri '^list-id:.*<your.list.id>$' messages" for
held posts via the problem list if you have list ID on (that's the
default for recent Mailman) and if that's not going to work you could
use "grep -rF 'y...@list.id' messages" for a less precise search.

It's not a good idea to delete them from the file system (I think
Mailman is robust to that but I'm not sure).  However, if one looks
like spam you could try working at a slightly lower level than
Postorius by using mailmanclient directly.  See
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/post-moderation.html.

If that doesn't work (for example listing the requests for a list
times out the same way in mailmanclient), you could try directly
querying the database server to see what's going on.  The check for an
unusual number of requests that might be an attack is to connect to
the database server with its command line utility.  I'm not on CLI
terms with MySQL but for PostgreSQL it's

$ su - mailman
$ psql
mailman=> select mailing_list_id, count(mailing_list_id) from _request group by 
mailing_list_id;
mailman=> select id, list_id from mailinglist;

and you can append " where id = $mailing_list_id" to the second to the
second one to find the List-Id for a specific mailing list.  That's
just plain SQL including the count function as far as I know, so
should work in any backend that Mailman can use.  If you're handy with
SQL you could do all that with a join but I'm not. ;-)

 > Any idea why this happens and how it can be solved?

Aside from a really astonishingly large number of pending requests (as
tested above with count()), perhaps there's something in the requests
themselves.  If there aren't literally thousands of requests for a
problem list you can list them with

mailman=> select key, mailing_list_id from _request;

Look for odd characters in the key field.  One oddity that I'mm pretty
sure is not a problem is something of the form "\r\n <message-id>" (my
instance lists those fine).  There's a bug in Exchange (IIRC) which
sometimes includes invalid characters (specifically "[" and "]") in
message IDs which I believe we worked around only quite recently,
although I don't recall if it affected APIs for requests.  Control
characters and non-ASCII might also cause trouble,

If your database server is MySQL, is it set up to handle the full
range of Unicode (I think the option is utf8mbcs)?  Lacking that is
known to cause problems when headers and maybe body contain emoticons
or other extended Unicode characters.  Again I don't recall if
crashing the REST runner is a known symptom.

If none of the above works, there's always the "hit it with a hammmer"
approach.  Have you tried restarting both Postorius and Mailman?  How
about restarting the database server?  How about all three?

As a last resort, it's probably possible to delete the requests from
the filesystem and the database by hand.  But I don't want to think
about that unless absolutely necessary.

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/IKDNPVDVAWAD6JCLJ6GK3K4XAVJISYCA/

This message sent to arch...@mail-archive.com

Reply via email to