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;
1h 24min ago
Duration: 33min 59.427s
Process: 1228 ExecStart=/opt/mailman/venv/bin/mailman start
(code=exited, status=0/SUCCESS)
Process: 2509 ExecStop=/opt/mailman/venv/bin/mailman stop (code=killed,
signal=TERM)
Main PID: 1253 (code=killed, signal=KILL)
CPU: 29.751s
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1700, in handle
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.callHandlers(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1762, in callHandlers
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
hdlr.handle(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/usr/lib/python3.12/logging/__init__.py", line 1028, in handle
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.emit(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: File
"/opt/mailman/venv/lib/python3.12/site-packages/mailman/core/logging.py",
line 85, in emit
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
self.handleError(record)
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]: Message:
'out runner caught SIGTERM. Stopping.'
Jan 30 17:00:27 list.louisvillecommunitygrocery.com mailman[1271]:
Arguments: ()
Thank you, Paul 'Arte Chambers' Robey 502-408-6922
On Thu, Jan 30, 2025 at 1:22 PM Arte Chambers <paul.m.robey@gmail.com> wrote:
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