Mailman 3 Service and Troubleshooting: Difference between revisions
LeWikiAdmin (talk | contribs) |
|||
Line 16: | Line 16: | ||
tail -f /home/mailman/we.lurk.org/web/logs/* | tail -f /home/mailman/we.lurk.org/web/logs/* | ||
tail -f /var/log/nginx/*log | 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 === | === 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 <code>/home/mailman/we.lurk.org/mm/var/archives/hyperkitty/spool</code> 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. | 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 <code>/home/mailman/we.lurk.org/mm/var/archives/hyperkitty/spool</code> 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. | ||
Latest revision as of 12:59, 2 December 2024
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