Mailman 3 Service and Troubleshooting

Service Configuration and Installation

There are two services needed:

systemctl status mailman3   # AKA mailman-core you only need this for lists to work
systemctl status mailmanweb # AKA hyperkitty, postorius, uwsgi, django hell, needed for the web interface

Troubleshooting

Where is everything logged?

Don't think you can start understand anything without at least doing the following:

• mailman core

tail -f /home/mailman/we.lurk.org/mm/var/logs/*
tail -f /var/log/mail.err /var/log/mail.log /var/log/mail.warn
journalctl --follow _SYSTEMD_UNIT=mailman3.service + _SYSTEMD_UNIT=mariadb.service

• web stuff

tail -f /home/mailman/we.lurk.org/web/logs/*
tail -f /var/log/nginx/*log

Mailman3 service does not (re)start

Quite often when mm3 crashes or when the server crashes and reboots, or if there has been a power shortage, mm3 leaves a stale lock which prevents the service to start again. This can be confirmed with:

systemctl status mailman3

Check for this line:

Error: A previous run of GNU Mailman did not exit cleanly (stale_lock).  Try using --force

If you see it, congrats, you have a stale lock, you can remove it like this:

 rm /home/mailman/we.lurk.org/mm/var/locks/master.lck

You can now restart mailman3 and mailmanweb

systemctl start mailman3
systemctl restart mailmanweb

Something is stuck in the Hyperkitty spool

Sometimes Hyperkitty does not like an email and won't be able to store it in its database. If that's the case there will be errors showing up both on the mailman3 and mailmanweb sides, notably about the relevant table/column in the mailman_web mariadb database that's struggling. Until this is solved the email will keep on being re-queued at /home/mailman/we.lurk.org/mm/var/archives/hyperkitty/spool and and new attempts to store the problematic email will happen every time the archiver is called, for instance when a new email is received on a list that has to be archived. This will not block the queue, just that the problem email will keep being tried over and over again until the problem is solved which can become quite expensive from a computational POV.

To inspect an item stuck in the queue you can do this:

su mailman  # ALWAYS
cd /home/mailman/we.lurk.org/mm/var/archives/hyperkitty/spool
mailman qfile 1234567890.1234567890.pck | less

Running mailman standalone

Only do this when manually troubleshooting otherwise this will conflict with systemctl initiated services.

• Mailman 3 relies on its own mailman user to handle the processing of the emails.

su mailman     # switch to the mailman user
cd             # make sure you cd to mailman's home !IMPORTANT

• You're now ready to control mailman
• Everything is handled with the mailman command line tool. Do not run these commands with another user!

mailman status       # report on the service
mailman start        # start mailman
mailman stop         # stop mailman
mailman restart      # stop and start mailman shorcut