and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"

I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.

There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?

Thank you, Paul 'Arte Chambers' Robey 502-408-6922

On Thu, Jan 30, 2025 at 12:09 PM Stephen J. Turnbull < turnbull@sk.tsukuba.ac.jp> wrote:

Arte Chambers via Mailman-users writes:

...

Hello I need help troubleshooting a problem with MM. The service is stopping

If you mean the message quoted below, the Mailman daemons are not stopping. You need to check the "Active", "Main PID", and "CGroup" fields of "systemctl status mailman3.service", or run "mailman status" directly to determine if Mailman is actually running properly or not.

...

and throwing this error in the mailman log "Exception in the HyperKitty archiver: 413 Request Entity Too Large"

I think a similar issue was reported last week, and Mark is more familiar with it. I seem to remember that it's possible that the message in question is a spam and has non-ASCII characters in the header or body of the message, which violates the email RFCs. Maybe if you move the oldest message in $var_dir/queue/archive (or maybe $var_dir/archiver/hyperkitty/spool) to $var_dir/queue/bad for later inspection things will start running again.

...

System CTL has this message and i'm not sure if it's relevant to the issue.

sudo systemctl status mailman3.service
systemd[1]: mailman3.service: Can't open PID file
/opt/mailman/mm/var/master.pid (yet?) after start: No such file or
directory

This isn't relevant. The initial 'mailman' process spawns a 'master' process then shuts down. 'master' takes enough time to get rolling that systemd can't find its pid file when 'mailman' shuts down, and systemd is too impatient to wait. That snippet is taken from the systemd journal, and does not reflect current status.

...

The MM Service will run for a while then shuts down.

This is probably normal, as explained above, unless you mean that "systemctl status mailman3.service" or "mailman status" reports that Mailman is not running. That should have some explanation in $log_dir/mailman.

Steve

Arte Chambers via Mailman-users writes:

The output from systemctl status after mailman has failed

~$ sudo systemctl status mailman3.service
× mailman3.service - GNU Mailing List Manager
     Loaded: loaded (/etc/systemd/system/mailman3.service; enabled; preset:
enabled)
     Active: failed (Result: oom-kill) since Thu 2025-01-30 17:00:27 UTC;

Ah, yes, that is as dead as the Monty Python parrot. How much memory and swap does the system have? (Note, you probably don't want to be using swap at all most of the time, this is to understand the "killed because the system ran out of free memory" oom-kill message.)

For comparison, I found that OOM kills were fairly frequent (~ once in 1-3 days) on a Digital Ocean droplet with 2GB of memory, and there was a dramatic reduction but not an elimination of OOM kills when I bumped it to 4GB. The two active apps were Mailman and Mediawiki, plus whatever Digital Ocean likes to run on its standard droplets.

Steve

Arte Chambers via Mailman-users writes:

There is only 1 .pck file in $var_dir/archiver/hyperkitty/spool and it is only 3.5M - Is there a way I can see what this pck file is?

That file would be related to the response. The *request* in the HyperKitty protocol is going to be much smaller. I believe the normal upper limit is 4kB. The previous report raised the limit on the request to 16kb or maybe 64kB, but then ran into a different problem. None of these numbers should be big enough to cause consistent OOM conditions unless your memory is truly tiny.

To view the file content, su to mailman, activate the virtual environment if you are using one, and type

mailman qfile $var_dir/archiver/hyperkitty/spool/xxxx-xxxx.pck

(with the correct name for the qfile, of course). mailman qfile -h will give you help, but IIRC qfile is one of the simplest subcommands: '-h' may be the only option it takes.

There are two parts to the output. The first is the Message object flattened to an RFC 822 message file. The second is a mapping of metadata that gives hints about what Mailman was doing with the file.

Steve

On 1/31/25 11:01, Arte Chambers via Mailman-users wrote:

Thanks, this was helpful. It was a message I sent to the list that was just an image attachment with no body text. I noticed this other thread about messages with attachments, without text discarded silently <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/thread/E...>. I am attaching the pickle file hoping that it helps anyone researching this issue.

I think the underlying issue is the same as in that thread. While your message has mime structure

multipart/mixed multipart/alternative text/plain <- empty text/html image/jpeg

If you have content filtering Collapse alternatives = yes, it will become

multipart/mixed text/plain <- empty image/jpeg

after collapsing alternatives and that will trigger the error. See https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/... for a patch (not yet tested) that I think will fix this.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 1/31/25 21:44, Stephen J. Turnbull wrote:

I don't think that's the best we can do, though. Especially if Convert HTML to plain is also yes, we want to preserve the HTML part and convert it, don't we?

Not if we're collapsing alternatives. If we're collapsing a multipart/alternative part with text/plain and text/html alternatives to just the first alternative we don't keep the text/html part.

The only html parts we keep and possibly convert to plain text are ones that aren't a second or later alternative in a multipart/alternative part.

I think a better (or additional) strategy would be to check the selected alternative for blank, and if so, drop it and try again for an appropriate type.

The collapsing of a two part multipart message with an empty first part into a single part message with just the second part is the last thing that's done after all other content filtering.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

On 2/1/25 03:08, Stephen J. Turnbull wrote:

Mark Sapiro writes:

...

Not if we're collapsing alternatives. If we're collapsing a multipart/alternative part with text/plain and text/html alternatives to just the first alternative we don't keep the text/html part.

I understand that's what we currently do. But I think that when the MUA provides an empty plain text part and a non-null HTML part, that's a mark of lazy MUA developers, not author intent. I think that it's very likely that the author would prefer the reader get converted HTML rather than a blank.

I think this is a request to change the collapsing of alternatives to not collapse to the first alternative if it is empty and a subsequent alternative is not. I see your point in general if the poster composes an HTML message and the MUA makes a multipart/alternative message with an empty text/plain part, but are there actually MUAs that do that? All the ones I'm aware of either make an HTML only message or attempt to make a reasonable text/plain alternative. Even Yahoo mail which does a horrible job of making the text/plain part (i.e. links which are copy/pasted in the HTML are dropped from the plain text) does make one.

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"

--000000000000da2dcc062cb38aa1

Content-Type: multipart/alternative; boundary="000000000000da2dcb062cb38aa0"

--000000000000da2dcb062cb38aa0
Content-Type: text/plain; charset="UTF-8"



--000000000000da2dcb062cb38aa0
Content-Type: text/html; charset="UTF-8"

<div dir="auto"><img src="cid:ii_194a8d787554eb091f02" style="max-width: 
100%; height: auto;"><br><br></div>

--000000000000da2dcb062cb38aa0--

--000000000000da2dcc062cb38aa1
Content-Type: image/jpeg; name="1000013462.jpg"
Content-Disposition: inline; filename="1000013462.jpg"
Content-Transfer-Encoding: base64
Content-ID: <ii_194a8d787554eb091f02>
X-Attachment-Id: ii_194a8d787554eb091f02

<base64 content>
--000000000000da2dcc062cb38aa1--

The HTML alternative only renders the jpg as an inline image. After current collapse alternatives this becomes

Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1"

--000000000000da2dcc062cb38aa1

Content-Type: text/plain; charset="UTF-8"


--000000000000da2dcc062cb38aa1
Content-Type: image/jpeg; name="1000013462.jpg"
Content-Disposition: inline; filename="1000013462.jpg"
Content-Transfer-Encoding: base64
Content-ID: <ii_194a8d787554eb091f02>
X-Attachment-Id: ii_194a8d787554eb091f02

<base64 content>
--000000000000da2dcc062cb38aa1--

which is an empty first part followed by the jpg part which is then further collapsed to just the jpg part

Content-Type: image/jpeg; name="1000013462.jpg"
Content-Disposition: inline; filename="1000013462.jpg"
Content-Transfer-Encoding: base64

<base64 content>

I.e. a single part message with content type image/jpeg.

If instead we collapsed the alternatives to the HTML part the message becomes

Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1"

--000000000000da2dcc062cb38aa1
Content-Type: text/html; charset="UTF-8"

<div dir="auto"><img src="cid:ii_194a8d787554eb091f02" style="max-width: 
100%; height: auto;"><br><br></div>

--000000000000da2dcc062cb38aa1
Content-Type: image/jpeg; name="1000013462.jpg"
Content-Disposition: inline; filename="1000013462.jpg"
Content-Transfer-Encoding: base64
Content-ID: <ii_194a8d787554eb091f02>
X-Attachment-Id: ii_194a8d787554eb091f02

<base64 content>
--000000000000da2dcc062cb38aa1--

and what that html part looks like after conversion to plain text depends on the configured command. With the default lynx the content is unchanged, put the type is text/plain which will render as the text with the image attached. With links the plain text content is empty which results again in a message with empty first part and image/jpeg second part.

In short, for this message at least, I see no real advantage to dropping the empty text/plain alternative vs. dropping the text/html alternative. Possibly there is a difference if we don't convert HTML to plain text in that some MUAs might render the jpeg inline as opposed to an attachment, but if we do convert with lynx the recipient sees a message with a body which is HTML tags rendered as text.

-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan