Cannot Run Web Frontend
I'm having trouble getting my web frontend working. When I try to access http://localhost/mailman3 I get a 503 error and the following in the apache2 error.log:
[Tue Dec 23 13:08:41.584412 2025] [proxy:error] [pid 132768] (111)Connection refused: AH00957: http: attempt to connect to 127.0.0.1:8000 (127.0.0.1:8000) failed [Tue Dec 23 13:08:41.584578 2025] [proxy_http:error] [pid 132768] [client 2600:1700:5cac:4600:fc36:9a27:6e66:44b:49658] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
This is the relevant part of apache2's 000-default.conf:
<IfModule mod_proxy.c> ProxyPreserveHost On ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" ProxyPass "/archives" "http://127.0.0.1:8000/archives" ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" ProxyPass "/admin" "http://127.0.0.1:8000/admin" ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" </IfModule>
What is a bit confusing but probably unrelated is this is in the virtual section for port 80 rather than port 443. I don't see any errors anywhere else.
On 12/23/25 10:18, dap1--- via Mailman-users wrote:
I'm having trouble getting my web frontend working. When I try to access http://localhost/mailman3 I get a 503 error and the following in the apache2 error.log:
[Tue Dec 23 13:08:41.584412 2025] [proxy:error] [pid 132768] (111)Connection refused: AH00957: http: attempt to connect to 127.0.0.1:8000 (127.0.0.1:8000) failed [Tue Dec 23 13:08:41.584578 2025] [proxy_http:error] [pid 132768] [client 2600:1700:5cac:4600:fc36:9a27:6e66:44b:49658] AH01114: HTTP: failed to make connection to backend: 127.0.0.1
Is mailman-web running? If so, what is the content of /etc/mailman3/uwsgi.ini if you are using uwsgi or /etc/mailman3/gunicorn.conf if you are using gunicorn?
What do you get from http://127.0.0.1:8000/mailman3?
This is the relevant part of apache2's 000-default.conf:
<IfModule mod_proxy.c> ProxyPreserveHost On ProxyPass "/mailman3" "http://127.0.0.1:8000/mailman3" ProxyPass "/archives" "http://127.0.0.1:8000/archives" ProxyPass "/accounts" "http://127.0.0.1:8000/accounts" ProxyPass "/admin" "http://127.0.0.1:8000/admin" ProxyPass "/user-profile" "http://127.0.0.1:8000/user-profile" </IfModule>
What is a bit confusing but probably unrelated is this is in the virtual section for port 80 rather than port 443. I don't see any errors anywhere else.
It needs to be there to support http://localhost/mailman3, but for https://localhost/mailman3, it needs to be in the port 443 section.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
How do I tell if mailman-web is running? There is no such service.
/etc/mailman3/gunicorn.py (recall I had to use py rather than conf to get it to work under Ubuntu):
# /etc/mailman3/gunicorn.conf # # bind = ['127.0.0.1:8000'] proc_name = "mailman-web" # # If you are having response issues you can tune the number of workers. # # The suggested starting point is (2 x $num_cores) + 1 # # See https://docs.gunicorn.org/en/latest/design.html#how-many-workers workers = 3 chdir = "/opt/mailman/mm" pidfile = "/opt/mailman/mm/var/gunicorn.pid" accesslog = "/opt/mailman/mm/var/logs/access.log" errorlog = "/opt/mailman/mm/var/logs/error.log" loglevel = 'debug'
I did notice one thing in the access.log that is wrong:
127.0.0.1 - - [24/Nov/2025:16:02:55 +0000] "GET /archives/api/mailman/urls?mlist=lllllllllll%40dddddd.net&msgid=705caa ab-afcc-4249-8d1d-cc48050d02d1%40bellsouth.net HTTP/1.1" 200 113 "-" "python-requests/2.32.5"
The mlist name is wrong. It should be lllllllllll%40gmail.com. I don't know where that is coming from but I'm sure it is left over from before I changed the list name.
When I include the port in the URL I get an unable to connect page.
P.S. Merry Christmas
How do I tell if mailman-web is running? There is no such service.
Which installation instructions did you follow from https://docs.mailman3.org/en/latest/install/install.html ?
If it was virtualenv (recommended) you have systemd services configured. Then run:
systemctl | grep mail
What does it show? Another method:
ps -ef | grep -i python
The mlist name is wrong. It should be lllllllllll%40gmail.com.
The mlist should be gmail.com?
Which official DNS domain are you using?
Usually mailing lists are set up on a DNS domain that you control. Are you an administrator of bellsouth.net or gmail.com? Or are those simply an end-user email account. You would register a domain with a registrar, and then create mailing lists on mydomain116.com, for example, or whatever the domain is.
Off-list.
Sam Darwin via Mailman-users writes:
The mlist should be gmail.com?
Here's the gist.
Dennis does not own a domain. He can't or won't pay for it. He wants to be and is trying to configure receiving his list's mail at gmail, getting it via fetchmail, processing the mailing list on a Linux box, and sending it back out via bellsouth.net's SMTP gateway.
He has been warned that this is fragile at best and impossible at worst, but he persists. *shrug* It's an interesting exercise in mail flow configuration.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
Sam Darwin via Mailman-users writes:
Googling: cheapest dns registrar, the results say "Register cheap domain names from $0.99" and "Starting at $0.99!"
If you're not careful, you may be signing up for a $50/year renewal or a very painful extraction of the domain from that registrar to somebody reasonable. Also, I'm like ... do I want to give my credit card data for $1 to somebody who probably keeps it in public AWS S3 bucket? (I did, but it was like 3 years before I bit the bullet on that. :-) But yeah.
Ok. It sounds like a difficult and convoluted exercise in mail flow configuration. :-)
:^) This is not the hill you want to defend unless you're really into it. I have seen worse inside of clients, LOL.
All that nonsense aside, thanks for your support! We regularly advertise the non-core developers on the list as a resource, and we appreciate you making that real.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
If it becomes impossible I will switch back to mailman2 which works on my CentOS system.
On 12/26/25 07:25, dap1--- via Mailman-users wrote:
If it becomes impossible I will switch back to mailman2 which works on my CentOS system.
This is a viable solution, but depending on your CentOS version, you may need to install Python 2 from source. See https://www.python.org/downloads/release/python-2718/
Much of your issue with Mailman 3 is because in MM 3, mail delivery to Mailman is different and list names include the domain. This prevents things which worked in your MM 2 configuration from working in MM 3.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro writes:
On 12/26/25 07:25, dap1--- via Mailman-users wrote:
If it becomes impossible I will switch back to mailman2 which
works on my CentOS system.
This is a viable solution[...].
Much of your issue with Mailman 3 is because in MM 3, mail delivery to Mailman is different and list names include the domain. This prevents things which worked in your MM 2 configuration from working in MM 3.
Sure, but I don't see why the right Postfix configuration wouldn't allow Mailman 3 to work as well as Mailman 2. This isn't a Mailman configuration problem as far as I can see -- just make a vanilla configuration based on the desired posting address. The problems are in routing to Mailman via fetchmail and Postfix. Since the tranport_maps take precedence over pretty much everything, and can be address-specific, just put the @gmail.com addresses he uses in there in the usual way. Then tell fetchmail to forward those addresses as is to Postfix's SMTP (depending on what other mail it needs to handle he might want to set up a configuration for an smtpd on port 8025, but probably not necessary). Maybe it's convenient for fetchmail to set Postfix's extension separator to '-' so that "cufsalumni-*@gmail.com" addresses are recognized as "cufsalumni@gmail.com" variants by Postfix. The transport_maps will pick those addresses (and only those cufsalumni*@gmail.com addresses of any gmail.com addresses) and forward them to Mailman, which will DTRT.
The problems I see with routing have to do with the impossibility of spoofing a Gmail origin for verifications and notifications, and anonymous lists etc that configure From to be the list. But that's going to be a problem for Mailman 2 as well AFAICS. His basic problem is that he chooses to operate with only one From address that is reliably deliverable in the current Internet, and unfortuately that's his personal address.
One solution I can think of would be to send the administrative list traffic out through Gmail's SMTP gateway using his registered cufsalumni-* accounts. That might work well -- it's Postfix's job so Mailman doesn't need to know about it, those should be infrequent at best, and they won't be relays from 3rd parties as mailing list posts usually are.
Dunno what's going on with his web configuration, tho.
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
I'm running everything in the virtual environment.
systemctl | grep mail
fetchmail.service loaded active exited LSB: init-Script for system wide fetchmail daemon mailman3.service loaded active running GNU Mailing List Manager
ps-ef | grep -i python
root 1120 1 0 Dec12 ? 00:00:00 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers root 1374 1 0 Dec12 ? 00:00:00 /usr/bin/python3 /usr/share/unattended-upgrades/unattended-upgrade-s hutdown --wait-for-signal mailman 74728 1 0 Dec18 ? 00:00:01 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/master -C /etc/m ailman3/mailman.cfg mailman 74787 74728 0 Dec18 ? 00:01:49 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=archive:0:1 mailman 74788 74728 0 Dec18 ? 00:01:21 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=bounces:0:1 mailman 74789 74728 0 Dec18 ? 00:01:51 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=command:0:1 mailman 74790 74728 0 Dec18 ? 00:01:51 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=in:0:1 mailman 74791 74728 0 Dec18 ? 00:00:38 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=lmtp:0:1 mailman 74792 74728 0 Dec18 ? 00:01:48 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=out:0:1 mailman 74793 74728 0 Dec18 ? 00:01:50 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=pipeline:0:1 mailman 74794 74728 0 Dec18 ? 00:02:19 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=rest:0:1 mailman 74795 74728 0 Dec18 ? 00:00:02 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=retry:0:1 mailman 74796 74728 0 Dec18 ? 00:00:13 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=task:0:1 mailman 74797 74728 0 Dec18 ? 00:01:50 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=virgin:0:1 mailman 74798 74728 0 Dec18 ? 00:01:48 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=digest:0:1 mailman 74804 74794 0 Dec18 ? 00:00:02 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=rest:0:1 mailman 74805 74794 0 Dec18 ? 00:00:03 /opt/mailman/venv/bin/python3 /opt/mailman/venv/bin/runner -C /etc/m ailman3/mailman.cfg --runner=rest:0:1 dap 165326 165254 0 10:27 pts/0 00:00:00 grep --color=auto -i python
Stephen pretty much summed up what I am trying to do. The only additional item is that I have to set up postfix to use a different relay for email from the list because my ISP munges the from headers. In any case none of this should effect the fact that the web frontend does not work.
On 12/24/25 08:14, dap1--- via Mailman-users wrote:
How do I tell if mailman-web is running? There is no such service.
In this case, the mailman-web service is gunicorn.
/etc/mailman3/gunicorn.py (recall I had to use py rather than conf to get it to work under Ubuntu):
It should have worked as gunicorn.conf despite the warning (not error) that it didn't have a .py extension.
# /etc/mailman3/gunicorn.conf # # bind = ['127.0.0.1:8000'] proc_name = "mailman-web" # # If you are having response issues you can tune the number of workers. # # The suggested starting point is (2 x $num_cores) + 1 # # See https://docs.gunicorn.org/en/latest/design.html#how-many-workers workers = 3 chdir = "/opt/mailman/mm" pidfile = "/opt/mailman/mm/var/gunicorn.pid" accesslog = "/opt/mailman/mm/var/logs/access.log" errorlog = "/opt/mailman/mm/var/logs/error.log" loglevel = 'debug'
I did notice one thing in the access.log that is wrong:
127.0.0.1 - - [24/Nov/2025:16:02:55 +0000] "GET /archives/api/mailman/urls?mlist=lllllllllll%40dddddd.net&msgid=705caa ab-afcc-4249-8d1d-cc48050d02d1%40bellsouth.net HTTP/1.1" 200 113 "-" "python-requests/2.32.5"
This request came from HyperKitty.
The mlist name is wrong. It should be lllllllllll%40gmail.com. I don't know where that is coming from but I'm sure it is left over from before I changed the list name.
To you have a hyperkitty list named lllllllllll%40dddddd.net. What does
SELECT name FROM hyperkitty_mailinglist;
show?
When I include the port in the URL I get an unable to connect page.
So nothing is listening on 127.0.0.1:8000 (localhost:8000 assuming the
localhost is 127.0.0.1 in /etc/hosts and not an IPv6 fe00::0 address)
What if any does netstat -lntp show is listening on 127.0.0.1:8000?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
SELECT name FROM hyperkitty_mailinglist; +--------------------------+ | name | +--------------------------+ | lllllllll@ddddddddd.net | | lllllllll@gmail.com | +--------------------------+ 2 rows in set (0.00 sec)
It seems just deleting lllllllll@ddddddddd.net is non-trivial.
Cannot delete or update a parent row: a foreign key constraint fails (mailmanweb.hyperkitty_email , CONSTRAINT hyperkitty_email_mailinglist_id_2c2b6f03_fk_hyperkitt FOREIGN KEY (mailinglist_id) REFERENCES hyperki tty_mailinglist (id))
netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 74794/python3 tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 74791/python3 tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 74696/master tcp 0 0 0.0.0.0:26 0.0.0.0:* LISTEN 1/init tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 160003/cupsd tcp6 0 0 :::443 :::* LISTEN 132763/apache2 tcp6 0 0 :::445 :::* LISTEN 1644/smbd tcp6 0 0 :::139 :::* LISTEN 1644/smbd tcp6 0 0 :::80 :::* LISTEN 132763/apache2 tcp6 0 0 :::25 :::* LISTEN 74696/master tcp6 0 0 :::26 :::* LISTEN 1/init tcp6 0 0 ::1:631 :::* LISTEN 160003/cupsd
I'm not using IPV6. Nothing is listening on 8000, just 8001 and 8024.
It appears that guicorn is not running if there is supposed to be a process by that name. There is also no such service.
I'm running everything in the virtual environment.
There is no such service.
If following the instructions from Virtualenv Installation https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-insta... it recommends creating a systemd service for gunicorn.
"Automatically starting Mailman-web. In order to automatically start at startup, you can create a second systemd service, mailmanweb.service. Create a new file /etc/systemd/system/mailmanweb.service" "If using Gunicorn, the ExecStart line above becomes...:"
Review that section, and create a systemd service called mailmanweb.service. It will start either uwsgi or gunicorn. Then start it. Debug from there.
I did all that but forgot about those services (mailmanweb and qcluster). For some reason it no longer says service does not exist. I didn't do anything I am aware of to make those come back. In any case they are now both running. Apparently the systemctl enable either went away or I forgot to do it. Now I am back to the Django CSRF problem. I will be going to the Django form to try to resolve it.
On 12/26/25 08:02, dap1--- via Mailman-users wrote:
SELECT name FROM hyperkitty_mailinglist; +--------------------------+ | name | +--------------------------+ | lllllllll@ddddddddd.net | | lllllllll@gmail.com | +--------------------------+ 2 rows in set (0.00 sec)
It seems just deleting lllllllll@ddddddddd.net is non-trivial. Cannot delete or update a parent row: a foreign key constraint fails (
mailmanweb.hyperkitty_email, CONSTRAINThyperkitty_email_mailinglist_id_2c2b6f03_fk_hyperkittFOREIGN KEY (mailinglist_id) REFERENCEShyperki tty_mailinglist(id))
This is not a critical issue so you can just ignore it until you get the web UI working at which time a Django superuser or the list owner can delete the list in HyperKitty's web UI.
If you want to do it in the database, I think you can first do
DELETE FROM hyperkitty_attachment WHERE hyperkitty_attachment.email_id IN (SELECT id FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net'));
to delete attachments and then do
DELETE FROM hyperkitty_email WHERE hyperkitty_email.mailinglist_id IN (SELECT id FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net');
to delete the emails and finally
DELETE FROM hyperkitty_mailinglist WHERE hyperkitty_mailinglist.name = 'lllllllll@ddddddddd.net';
But this may possibly run into other foreign key constraint issues. It's probably easier to get the web UI up and do it there.
netstat -lntp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.54:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 1644/smbd tcp 0 0 127.0.0.1:8001 0.0.0.0:* LISTEN 74794/python3 tcp 0 0 127.0.0.1:8024 0.0.0.0:* LISTEN 74791/python3 tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 1103/systemd-resolv tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 74696/master tcp 0 0 0.0.0.0:26 0.0.0.0:* LISTEN 1/init tcp 0 0 127.0.0.1:33060 0.0.0.0:* LISTEN 1407/mysqld tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 160003/cupsd tcp6 0 0 :::443 :::* LISTEN 132763/apache2 tcp6 0 0 :::445 :::* LISTEN 1644/smbd tcp6 0 0 :::139 :::* LISTEN 1644/smbd tcp6 0 0 :::80 :::* LISTEN 132763/apache2 tcp6 0 0 :::25 :::* LISTEN 74696/master tcp6 0 0 :::26 :::* LISTEN 1/init tcp6 0 0 ::1:631 :::* LISTEN 160003/cupsd
I'm not using IPV6. Nothing is listening on 8000, just 8001 and 8024.
It appears that guicorn is not running if there is supposed to be a process by that name. There is also no such service.
See https://docs.mailman3.org/en/latest/install/virtualenv.html#automatically-st...
Particularly the part that says:
If using Gunicorn, the ExecStart line above becomes:
ExecStart=/opt/mailman/venv/bin/gunicorn -c /etc/mailman3/gunicorn.conf mailman_web.wsgi:application
Do you have that and is the mailmanweb service running?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
dap1--- via Mailman-users writes:
What is a bit confusing but probably unrelated is this is in the virtual section for port 80 rather than port 443.
Since Mailman's ports (usually 8000 and 8001) are normally not exposed directly to the Internet, only through the ProxyPass configuration, there's no point to TLS (HTTPS, port 443). You could do it, but you'd just be wasting CPU cycles in most configurations.
Otherwise, I have nothing to add to Mark's comments. "Connection refused" almost always means that there's nothing listening on that port. Then, either mailman-web is not running or it's listening somewhere else.
Steve
-- GNU Mailman consultant (installation, migration, customization) Sirius Open Source https://www.siriusopensource.com/ Software systems consulting in Europe, North America, and Japan
participants (4)
-
dap1@bellsouth.net -
Mark Sapiro -
Sam Darwin -
Stephen J. Turnbull