Mailman 3 Service and Troubleshooting: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
| (6 intermediate revisions by the same user not shown) | |||
| Line 5: | Line 5: | ||
systemctl status mailmanweb # AKA hyperkitty, postorius, uwsgi, django hell, needed for the web interface | systemctl status mailmanweb # AKA hyperkitty, postorius, uwsgi, django hell, needed for the web interface | ||
== | == Troubleshooting == | ||
=== Where is everything logged? === | |||
Only do this when manually troubleshooting otherwise this will conflict with <code>systemctl</code> initiated services. | 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 | |||
=== 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. | |||
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 <code>systemctl</code> initiated services.''' | |||
* Mailman 3 relies on its own mailman user to handle the processing of the emails. | * Mailman 3 relies on its own mailman user to handle the processing of the emails. | ||
su mailman # switch to the mailman user | su mailman # switch to the mailman user | ||
| Line 18: | Line 37: | ||
mailman stop # stop mailman | mailman stop # stop mailman | ||
mailman restart # stop and start mailman shorcut | mailman restart # stop and start mailman shorcut | ||
Latest revision as of 14:52, 1 January 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
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