Search results for query "sapiro"
- 6105 messages
[MM3-users] Re: Held messages not delivered after approval
by Krinetzki, Stephan
>The django-admin commands aren't directly related, I'm going to ignore them for now. The only thing I know for *sure* runs at midnight daily is "mailman digests --send". On my Debian Linode, the default (which I left alone) is for logrotate's cron job to live in >/etc/cron.daily, which is run at 06:25 daily using "run-parts". (This is quite a common setup on Linux.) So we need to know where the logrotate job is specified (crontab, cron.d, or cron.daily) and at what time (@daily =
>midnight) to be sure that the mailman restart is related to the bad and shunt queue files.
The logrotate is executed by a system Timer (Rocky 9 OS btw) and is planned for:
Tue 2025-08-05 00:00:00 CEST 7h left Mon 2025-08-04 00:00:00 CEST 16h ago logrotate.timer logrotate.service
So every day at midnight.
>That is not normal. Your control process is crashing every 15-20 seconds. I think it probably is a problem with the digests, not with the restart. What appears to be happening is that the digest process gets triggered, it creates a message and queues it, then fails to >send it so nastily that Mailman restarts (or stops and something like systemd restarts it). On restart, Mailman finds the digest message (probably in the out queue), tries to send it again, crashes again, and eventually decides that isn't going to work, sends it to bad, >and stops crashing.
I saw this but I don't have any idea how this happens. Currently there are ~42 Mails after 'mailman unshunt' and I think, mailman loops over them (queue doesn't get shorter). But mails are delivered for a lot of lists.
>According to the config you posted earlier, you're sending most channels to separate log files. Have you checked any of them other than mailman.log and smtp.log? Also, note that httpd.log and error.log are normally used by Mailman core's gunicorn (ie, the REST >API). I'm not sure what effect directing Mailman's error channel to error.log will have, but I suspect you could end up losing logs or having text from different sources mixed.
So I should update my logging config. Do you have a good example or maybe even the dist?
--
Stephan Krinetzki
IT Center
Gruppe: Anwendungsbetrieb und Cloud
Abteilung: Systeme und Betrieb
RWTH Aachen University
Seffenter Weg 23
52074 Aachen
Tel: +49 241 80-24866
Fax: +49 241 80-22134
krinetzki(a)itc.rwth-aachen.de
www.itc.rwth-aachen.de
Social Media Kanäle des IT Centers:
https://blog.rwth-aachen.de/itc/
https://www.facebook.com/itcenterrwth
https://www.linkedin.com/company/itcenterrwth
https://twitter.com/ITCenterRWTH
https://www.youtube.com/channel/UCKKDJJukeRwO0LP-ac8x8rQ
-----Original Message-----
From: Stephen J. Turnbull <steve(a)turnbull.jp>
Sent: Monday, August 4, 2025 1:51 PM
To: Krinetzki, Stephan <Krinetzki(a)itc.rwth-aachen.de>
Cc: Mark Sapiro <mark(a)msapiro.net>; mailman-users(a)mailman3.org
Subject: RE: [MM3-users] Re: Held messages not delivered after approval
Krinetzki, Stephan writes:
> /opt/mailman/var/queue/bad:
> -rw-rw---- 1 mailman mailman 221723 Aug 1 17:26 1754061973.4885209+46b1ae3716439bf3ef98090296dfce0320fc3017.psv
This one might be spam, but it's weird that it managed to get pickled but can't be read.
> -rw-rw---- 1 mailman mailman 32912 Aug 2 00:00 1754085602.191851+3576cf33232db110fa7761233f67245564553652.psv
> -rw-rw---- 1 mailman mailman 416 Aug 2 00:00 1754085604.0204346+ad485da0c45cb0ad17a5dc42613c3eb3f313c20e.psv
> -rw-rw---- 1 mailman mailman 1407649 Aug 2 00:00 1754085623.275817+f23139c8127c454b4fe65453af3db18e558b0e87.psv
> -rw-rw---- 1 mailman mailman 1407634 Aug 2 00:02 1754085729.3529432+1643f907bac39a22a7d71e50b031c4f8a574082c.psv
I have no clue about these four (see below for comments on cron).
> /opt/mailman/var/queue/out:
Looks normal for your configuration.
> /opt/mailman/var/queue/shunt:
I don't understand why on August 1st you see shunts at intervals throughout the working day, then suddenly on the 2nd they all happen at midnight.
Have you tried "mailman unshunt"? If not what happens when you do?
If the shunts are happening because of the restart, then they should go through on unshunt. If they don't, there's some other problem.
You can also try renaming the .psvs to .pck, and check the metadata in the pickle for which queue to move it to. That's more risky, and you shouldn't try it if the output of "mailman qfile" isn't as expected.
> I don't see here a problem. But the timestamp seems to be related > to the restart of mailman. Can I skip this in the logrotate?
As I mentioned before, there was (and may still be) a bug in Mailman's logging such that Mailman fails to reopen the logs, and typically after a couple of days you end up with a nameless open file collecting the logs and uselessly consuming more and more disk space. The restart is intended to work around this problem.
> Btw: The crontab is the following:
> @daily mailman cd /opt/mailman; source /opt/mailman/mailman-venv/bin/activate; /opt/mailman/mailman-venv/bin/mailman digests --send > /dev/null 2>&1
The django-admin commands aren't directly related, I'm going to ignore them for now. The only thing I know for *sure* runs at midnight daily is "mailman digests --send". On my Debian Linode, the default (which I left alone) is for logrotate's cron job to live in /etc/cron.daily, which is run at 06:25 daily using "run-parts". (This is quite a common setup on Linux.) So we need to know where the logrotate job is specified (crontab, cron.d, or cron.daily) and at what time (@daily =
midnight) to be sure that the mailman restart is related to the bad and shunt queue files.
> So i checked the mailman.log:
>
> [2025-08-01 00:00:02 +0200] [324558] [INFO] Shutting down: Master > [2025-08-01 00:00:23 +0200] [567059] [INFO] Shutting down: Master > [2025-08-01 00:00:42 +0200] [567206] [INFO] Shutting down: Master > [2025-08-01 00:01:01 +0200] [567278] [INFO] Shutting down: Master > [2025-08-01 00:01:34 +0200] [567379] [INFO] Shutting down: Master > [2025-08-01 00:01:52 +0200] [567516] [INFO] Shutting down: Master > [2025-08-01 00:02:11 +0200] [567646] [INFO] Shutting down: Master
That is not normal. Your control process is crashing every 15-20 seconds. I think it probably is a problem with the digests, not with the restart. What appears to be happening is that the digest process gets triggered, it creates a message and queues it, then fails to send it so nastily that Mailman restarts (or stops and something like systemd restarts it). On restart, Mailman finds the digest message (probably in the out queue), tries to send it again, crashes again, and eventually decides that isn't going to work, sends it to bad, and stops crashing.
There's normally lot more chatter at startup and shutdown, for example about runners being started. That's probably because you have that redirected to a separate log file, or maybe that information doesn't get output with a log level of "warn". Maybe the crash information is in the runner.log.
According to the config you posted earlier, you're sending most channels to separate log files. Have you checked any of them other than mailman.log and smtp.log? Also, note that httpd.log and error.log are normally used by Mailman core's gunicorn (ie, the REST API). I'm not sure what effect directing Mailman's error channel to error.log will have, but I suspect you could end up losing logs or having text from different sources mixed.
I haven't thought about it carefully, but I would have separate logs for bounces, subscriptions, smtp, and nntp because they are quite separate. Everything else would go into mailman.log, because that makes it easier to trace a single message through the whole process.
Until you know that you don't need it, I would have most channels at the info level. The debug level is almost never useful unless you're a developer trying to fix something (vs a troubleshooter trying to diagnose the problem). The logs compress very well (often 70% reduction), so it's generally a good idea to include the extra information at info level. Remember, the real explosion is logging is that outgoing mail gets logged up to 43k times per incoming post. Of course you can do quite a bit better if you can sacrifice the personalized footers, but most sites don't anymore because there are strict rules about convenience of unsubscription.
> Well...i will stop the restart after the log rotate today.
You can do that if you want, but it's likely that you'll end up losing logs.
> >And for every one of those shunted messages there should be an > >exception with traceback logged in mailman.log. Those tracebacks > >should be helpful.
>
> If there were any. Maybe the "debug" level should be "info". But > for which logs?
Setting the channel to "debug" gives maximum verbosity, and unhandled exceptions are logged at "warn" or "error" level (maximum severity).
> Maybe the restart at night after the lograte maybe the issue.
Not with Mailman bouncing up and down pretty much as fast as it can.
The restart can only account for one restart, the other 6 were caused by something else.
--
GNU Mailman consultant (installation, migration, customization)
Sirius Open Source https://www.siriusopensource.com/
Software systems consulting in Europe, North America, and Japan
6 months, 2 weeks
[MM3-users] Re: MTA setup
by Arte Chambers
Update: After changing the DMARC settings messages are now going through to
my inbox, however they are still not being archived.
Thank you,
Paul 'Arte Chambers' Robey
502-408-6922
On Mon, Dec 23, 2024 at 12:01 PM Arte Chambers <paul.m.robey(a)gmail.com>
wrote:
> Output from mailman log after sending a test message to the list:
>
> Dec 23 16:52:23 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:52:23 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:52:23 2024 (684048) Could not archive the message with id <
> CAM05vAcLAhTzjdcFKsp6i0RSKpfhQ9H_KpOLJyVmNZy4KcaWzQ(a)mail.gmail.com>
> Dec 23 16:52:23 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAM05vAcLAhTzjdcFKsp6i0RSKpfhQ9H_KpOLJyVmNZy4KcaWzQ(a)mail.gmail.com>)
> Dec 23 16:52:23 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:52:23 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:52:23 2024 (684058) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
>
>
> I sent another test after changing the DMARC settings for the list
> mailman.log:
>
> Dec 23 16:58:48 2024 (684052) ACCEPT:
> <CAM05vAcs3mL2MMX_NNsrHHyLz8p_tTvCHRRiROCgt=U5Oi6x5w(a)mail.gmail.com>
> Dec 23 16:58:49 2024 (684063) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:49 2024 (684063) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684058) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) Could not archive the message with id
> <CAPesOD2KavP948Oq6n9mvYF9WW3-sXRRTxAMm2roMgzL+=s8Dw(a)mail.gmail.com>
> Dec 23 16:58:50 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAPesOD2KavP948Oq6n9mvYF9WW3-sXRRTxAMm2roMgzL+=s8Dw(a)mail.gmail.com>)
> Dec 23 16:58:50 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:50 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:50 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) Could not archive the message with id
> <CAM05vAcN5RZ3Mzg-xXd-u=X7_inDULsBR8A=ehPwk5oy+y+ZLg(a)mail.gmail.com>
> Dec 23 16:58:50 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAM05vAcN5RZ3Mzg-xXd-u=X7_inDULsBR8A=ehPwk5oy+y+ZLg(a)mail.gmail.com>)
> Dec 23 16:58:50 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:50 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:50 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) Could not archive the message with id <
> CAM05vAfoHZmvu42wojk5SpCeynQs4rM01iKw+U5KpWMChHXGWw(a)mail.gmail.com>
> Dec 23 16:58:50 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAM05vAfoHZmvu42wojk5SpCeynQs4rM01iKw+U5KpWMChHXGWw(a)mail.gmail.com>)
> Dec 23 16:58:50 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:50 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:50 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) Could not archive the message with id <
> CAM05vAdx7VGPpApAEtF_J8RW2eXBoS6D-_6BCp8wKGUF5_Cyyw(a)mail.gmail.com>
> Dec 23 16:58:50 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAM05vAdx7VGPpApAEtF_J8RW2eXBoS6D-_6BCp8wKGUF5_Cyyw(a)mail.gmail.com>)
> Dec 23 16:58:50 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:50 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:50 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:50 2024 (684048) Could not archive the message with id
> <CAPesOD1y0fEaG=GFodz=Lgs1m_hqRErPnQcpXCNtKsBbJ=BJ7Q(a)mail.gmail.com>
> Dec 23 16:58:50 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAPesOD1y0fEaG=GFodz=Lgs1m_hqRErPnQcpXCNtKsBbJ=BJ7Q(a)mail.gmail.com>)
> Dec 23 16:58:50 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:50 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684058) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id
> <CAM05vAdLwKNNLgFGMKPm_yv6YykcL=SynJSDYf70hyGufryyCw(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAM05vAdLwKNNLgFGMKPm_yv6YykcL=SynJSDYf70hyGufryyCw(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id
> <CAM05vAcG99mHboPkZ82q=+d+uB3L3+iEmhwSCNAVFwSua80LoQ(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAM05vAcG99mHboPkZ82q=+d+uB3L3+iEmhwSCNAVFwSua80LoQ(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id <
> CAPesOD1ZJG3zyEagCqYd+nce76g_hbwJK9wQF51Pi6iyJhBKvA(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAPesOD1ZJG3zyEagCqYd+nce76g_hbwJK9wQF51Pi6iyJhBKvA(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id <
> CAM05vAdR3n-zhrLHCPhzi4xHOkLsmTUUgXnwgSwJM1oao2j3tg(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAM05vAdR3n-zhrLHCPhzi4xHOkLsmTUUgXnwgSwJM1oao2j3tg(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id <
> CAM05vAcLAhTzjdcFKsp6i0RSKpfhQ9H_KpOLJyVmNZy4KcaWzQ(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message <
> CAM05vAcLAhTzjdcFKsp6i0RSKpfhQ9H_KpOLJyVmNZy4KcaWzQ(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684048) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/archive:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
> Dec 23 16:58:51 2024 (684048) Could not archive the message with id
> <CAM05vAcs3mL2MMX_NNsrHHyLz8p_tTvCHRRiROCgt=U5Oi6x5w(a)mail.gmail.com>
> Dec 23 16:58:51 2024 (684048) archiving failed, re-queuing (mailing-list
> testing.list.louisvillecommunitygrocery.com, message
> <CAM05vAcs3mL2MMX_NNsrHHyLz8p_tTvCHRRiROCgt=U5Oi6x5w(a)mail.gmail.com>)
> Dec 23 16:58:51 2024 (684048) Exception in the HyperKitty archiver:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> Dec 23 16:58:51 2024 (684048) Traceback (most recent call last):
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 158, in _archive_message
> url = self._send_message(mlist, msg)
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> File
> "/opt/mailman/venv/lib/python3.12/site-packages/mailman_hyperkitty/__init__.py",
> line 228, in _send_message
> raise ValueError(result.text)
> ValueError:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
>
> Dec 23 16:58:51 2024 (684058) HyperKitty failure on
> http://127.0.0.1:8000/archives/api/mailman/urls:
> <!doctype html>
> <html lang="en">
> <head>
> <title>Bad Request (400)</title>
> </head>
> <body>
> <h1>Bad Request (400)</h1><p></p>
> </body>
> </html>
> (400)
>
> Thank you,
> Paul 'Arte Chambers' Robey
> 502-408-6922
>
>
> On Sun, Dec 22, 2024 at 11:31 PM Mark Sapiro <mark(a)msapiro.net> wrote:
>
>> On 12/22/24 20:10, Arte Chambers via Mailman-users wrote:
>> > I'm not sure how to check mailmans shunt queue.
>>
>> `ls var/queue/shunt`
>>
>> > I'm not seeing any errors in mailman logs
>> >
>> > There are several .pck files in Mailman's
>> > var/archives/hyperkitty/spool/
>> These are message that failed to archive. There should be messages in
>> mailman.log about these failures indicating what the issue is.
>>
>> > I can send email from the server using mail utilities as long as the
>> "from
>> > email address" contains the server's domain name. I also notice that in
>> > this MM3-Users list the "from" email shows senders(a)emailaddress.com VIA
>> > mailman3.org. I'm wondering if I've missed something that would allow
>> my
>> > server to behave this way.
>>
>>
>> In the list's Settings -> DMARC Mitigations set DMARC mitigation action
>> to Replace From: with list address and set DMARC Mitigate
>> unconditionally to Yes.
>>
>> --
>> Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
>> San Francisco Bay Area, California better use your sense - B. Dylan
>>
>> _______________________________________________
>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>> Archived at:
>> https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message…
>>
>> This message sent to paul.m.robey(a)gmail.com
>>
>
1 year, 1 month
[MM3-users] Re: A little stuck with installation of MM3 - ModuleNotFoundError: No module named 'flufl.lock'
by Odhiambo Washington
On Sun, 26 Jul 2020 at 00:17, Mark Sapiro <mark(a)msapiro.net> wrote:
> On 7/25/20 12:54 PM, Odhiambo Washington wrote:
> >
> > Finally, I have adapted your init script to get some rudimentary one
> that I
> > could use on FreeBSD.
> > I have to change /opt/mailman to be owned by mailman3:mailman3 (because I
> > have "live" MLs on this server, using mailman-2.1.34.
> > I am not sure if they can co-exist. I suppose they could, but what might
> be
> > the security implication, if any??
>
> I manage more than one server that supports both Mailman 2.1 and Mailman
> 3 running as user `mailman`. I'm not aware of any security issues.
>
>
> > This is what the init script looks like (rudimentary!!):
> > (venv) [root@gw /usr/local/etc/rc.d]# less mailman3
> > ### BEGIN INIT INFO
> > # Provides: GNU Mailman
> > # Short-Description: Mailman3 Service
> > # Description: service control for Mailman3
> > ### END INIT INFO
> >
> >
> PATH=/opt/mailman/mm/bin:/opt/mailman/mm/venv/bin:/usr/sbin:/usr/bin:/bin:/sbin:
> > DESC="GNU Mailman service"
> > DAEMON=/opt/mailman/mm/bin/mailman
> > NAME=mailman
> > USER=mailman3
> > GROUP=mailman3
> >
> > # Needed by click
> > export LANG=en_US.UTF-8
> >
> > # Exit if the package is not installed
> > [ -x "$DAEMON" ] || exit 0
> >
> > # Load the VERBOSE setting and other rcS variables
> > #. /lib/init/vars.sh
> >
> > # Define LSB log_* functions.
> > # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
> > # and status_of_proc is working.
> > #. /lib/lsb/init-functions
> >
> > case "$1" in
> > start)
> > [ "$VERBOSE" != no ] && echo "Starting $DESC" "$NAME"
> > # use --force to remove a stale lock.
> > /usr/local/bin/sudo -u $USER $DAEMON start --force
>
> T don't recommend using --force in init scripts. It *shouldn't* matter
> because even with --force the master shouldn't break the lock if the pip
> that set it still exists, but I prefer not to use it.
>
>
> > ;;
> > stop)
> > [ "$VERBOSE" != no ] && echo "Stopping $DESC" "$NAME"
> > /usr/local/bin/sudo -u $USER $DAEMON stop
> > ;;
> > status)
> > /usr/local/bin/sudo -u $USER $DAEMON status
> > ;;
> > reopen)
> > /usr/local/bin/sudo -u $USER $DAEMON reopen
> > ;;
> > restart)
> > log_daemon_msg "Restarting $DESC" "$NAME"
> > /usr/local/bin/sudo -u $USER $DAEMON restart
> > ;;
> > *)
> > echo "Usage: $SCRIPTNAME {start|stop|status|reopen|restart}" >&2
> > exit 3
> > ;;
> > esac
> >
> > It does start mailman3 for sure, but also complains after a few seconds
> > with the message:
> >
> > (venv) [root@gw /usr/local/etc/rc.d]#
> >
> */opt/mailman/mm/venv/lib/python3.7/site-packages/mailman-3.3.2b1-py3.7.egg/mailman/rest/wsgiapp.py:180:
> > DeprecatedWarning: Call to deprecated function __init__(...). API class
> may
> > be removed in a future release, use falcon.App instead.*
> > * **kws)*
>
>
> Hmm... strange, My various MM 3 installs are running falcon 1.4.0, 2.0.0
> and 3.0.0a1 and I don't see this warning, but it is only a deprecation
> warning. It doesn't mean it won't work.
>
>
> > But:
> >
> > (venv) [root@gw /usr/local/etc/rc.d]# ps ax | grep mailman
> ...
>
> It seems Mailman core and the rest runner and its workers are all running.
>
>
> >
> > Assuming that I am using mod_wsgi with Apache, and that I have configured
> > apache right using
> >
> https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…
> > ..
> > should I be able to access the MM3 web UI??
>
> Yes, I think so.
>
>
> > At that point, I am feeling somewhat confused as to what to try next.
> >
> > (venv) [root@gw /opt/mailman/mm/var/logs]# less mailman.log
> > Jul 25 22:53:16 2020 (40670) Master started
> > Jul 25 22:53:18 2020 (42036) bounces runner started.
> > Jul 25 22:53:18 2020 (45205) out runner started.
> > Jul 25 22:53:19 2020 (41191) archive runner started.
> > Jul 25 22:53:19 2020 (46670) retry runner started.
> > Jul 25 22:53:19 2020 (44567) nntp runner started.
> > Jul 25 22:53:19 2020 (43069) in runner started.
> > Jul 25 22:53:19 2020 (46960) virgin runner started.
> > Jul 25 22:53:20 2020 (45720) pipeline runner started.
> > Jul 25 22:53:20 2020 (47326) digest runner started.
> > Jul 25 22:53:20 2020 (43755) lmtp runner started.
> > Jul 25 22:53:20 2020 (45922) rest runner started.
> > [2020-07-25 22:53:20 +0300] [45922] [INFO] Starting gunicorn 20.0.4
> > [2020-07-25 22:53:20 +0300] [45922] [INFO] Listening at:
> > http://127.0.0.1:8001 (45922)
> > [2020-07-25 22:53:20 +0300] [45922] [INFO] Using worker: sync
> > [2020-07-25 22:53:20 +0300] [54732] [INFO] Booting worker with pid: 54732
> > [2020-07-25 22:53:20 +0300] [55467] [INFO] Booting worker with pid: 55467
> > Jul 25 22:53:21 2020 (42743) command runner started.
>
>
> The above is all fine, but it is just Mailman core.
>
>
> > How do I access the web UI for MM3 now?
>
>
> The Apache config points to /opt/mailman/mm/wsgi.py, a sampole of which
> is at
> <
> https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…
> >.
> Do you have that?
>
Yes, I have that file.
> If you installed the Apache config literally, the location for Mailman 3
> is defined by
> <
> https://wiki.list.org/DOC/Mailman%203%20installation%20experience?action=At…
> >
> and the URL would be http(s)://your.server/mm3 - have you tried that?
>
>
There is still some confusion on my part about the directives in the file
so allow me to seek some clarifications.
The following are the contents of a file I have created and placed in my
Apache Includes/ directory.
I was hoping that with it, I can now access http://lists.my.server/mm3 and
get the UI.
<CUT>
# Global section
WSGIDaemonProcess mailman-web display-name=mailman-web
maximum-requests=1000 umask=0002 user=mailman3 \
group=mailman3
python-path=/opt/mailman/mm/venv/lib/python3.7/site-packages:/opt/mailman/mm/venv/lib/python3.7
\
python-home=/opt/mailman/mm/venv home=/opt/mailman/mm/var
WSGIRestrictSignal Off
<VirtualHost *:80>
ServerName lists.my.server
ServerAdmin odhiambo(a)gmail.com
# (I'm not sure that WSGIRestrictSignal Off is required, but it was in the
# provided example so I kept it. I also made changes to WSGIDaemonProcess
# based on my own mod_wsgi experience elsewhere.)
ErrorLog /var/log/myserver-error.log
LogLevel debug
# This goes in the VirtualHost block for the domain.
# Mailman 3 stuff
Alias /static "/var/spool/mailman-web/static" *<----- Where is this
directory supposed to be and what/who creates it and with what permissions?*
<Directory "/var/spool/mailman-web/static">
Require all granted
</Directory>
WSGIScriptAlias /mm3 /opt/mailman/mm/wsgi.py
<Directory "/opt/mailman/mm/">
<Files wsgi.py>
Order deny,allow
Allow from all
Require all granted
</Files>
WSGIProcessGroup mailman-web
</Directory>
</VirtualHost>
</CUT-HERE>
I end up with an "Internal server error" and from the error log I see:
[Sun Jul 26 12:04:43.444127 2020] [wsgi:info] [pid 6444] [remote
197.232.81.246:53383] mod_wsgi (pid=6444, process='mailman-web',
application='lists.my.server|/mm3'): Loading Python script file
'/opt/mailman/mm/wsgi.py'.
[Sun Jul 26 12:04:44.091922 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] mod_wsgi (pid=6444): Failed to exec Python script
file '/opt/mailman/mm/wsgi.py'.
[Sun Jul 26 12:04:44.092006 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] mod_wsgi (pid=6444): Exception occurred processing
WSGI script '/opt/mailman/mm/wsgi.py'.
[Sun Jul 26 12:04:44.092940 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] Traceback (most recent call last):
[Sun Jul 26 12:04:44.093019 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File "/opt/mailman/mm/wsgi.py", line 38, in <module>
[Sun Jul 26 12:04:44.093029 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] application = get_wsgi_application()
[Sun Jul 26 12:04:44.093048 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/core/wsgi.py",
line 12, in get_wsgi_application
[Sun Jul 26 12:04:44.093057 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] django.setup(set_prefix=False)
[Sun Jul 26 12:04:44.093071 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/__init__.py",
line 19, in setup
[Sun Jul 26 12:04:44.093090 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] configure_logging(settings.LOGGING_CONFIG,
settings.LOGGING)
[Sun Jul 26 12:04:44.093108 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/conf/__init__.py",
line 76, in __getattr__
[Sun Jul 26 12:04:44.093117 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] self._setup(name)
[Sun Jul 26 12:04:44.093130 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/conf/__init__.py",
line 63, in _setup
[Sun Jul 26 12:04:44.093138 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] self._wrapped = Settings(settings_module)
[Sun Jul 26 12:04:44.093158 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/opt/mailman/mm/venv/lib/python3.7/site-packages/Django-3.0.8-py3.7.egg/django/conf/__init__.py",
line 142, in __init__
[Sun Jul 26 12:04:44.093166 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] mod =
importlib.import_module(self.SETTINGS_MODULE)
[Sun Jul 26 12:04:44.093179 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File
"/usr/local/lib/python3.6/importlib/__init__.py", line 126, in import_module
[Sun Jul 26 12:04:44.093187 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] return _bootstrap._gcd_import(name[level:],
package, level)
[Sun Jul 26 12:04:44.093210 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File "<frozen importlib._bootstrap>", line 994, in
_gcd_import
[Sun Jul 26 12:04:44.093224 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File "<frozen importlib._bootstrap>", line 971, in
_find_and_load
[Sun Jul 26 12:04:44.093239 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] File "<frozen importlib._bootstrap>", line 953, in
_find_and_load_unlocked
[Sun Jul 26 12:04:44.093265 2020] [wsgi:error] [pid 6444] [remote
197.232.81.246:53383] ModuleNotFoundError: No module named 'settings'
--
Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254 7 3200 0004/+254 7 2274 3223
"Oh, the cruft.", grep ^[^#] :-)
5 years, 6 months
[MM3-users] Re: error changed after restart
by Guillermo Hernandez (Oldno7)
On 7/2/21 19:04, Abhilash Raj wrote:
>
> On Sun, Feb 7, 2021, at 1:07 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>> On 6/2/21 21:19, Abhilash Raj wrote:
>>>
>>> On Sat, Feb 6, 2021 at 19:44, Guillermo Hernandez (Oldno7) via
>>> Mailman-users <mailman-users(a)mailman3.org> wrote:
>>>> On 6/2/21 18:08, Abhilash Raj wrote:
>>>>
>>>> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via
>>>> Mailman-users wrote:
>>>>
>>>> I restarted de server and the error changed. Now the log
>>>> shows "KeyError: 'subscription_mode'":
>>>>
>>>> Did you also restart Mailman Core after the upgrade?
>>>>
>>>> Yes, indeed: I stopped mailman core and all the processes related.
>>>> Did the upgrades. Started all again. Find the errors in the web user
>>>> interface. Stopped all again. Looked for errors in the log. Restarted
>>>> the complete server. Found the second error that this second mail is
>>>> about to. It happens when, in the main page that shows all the lists
>>>> you click to see one of them. It seems to me that it has been
>>>> database structure changes in django that the upgrade is not aware...
>>>> but it's a very long shot from my side.
>>> `subscription_mode` was added in Mailman Core 3.3.2 and it is actually
>>> a derived atrribute and not stored in Database. Mailman's API should be
>>> returning this attribute for each Member, but for some reason it seems
>>> to me like it isn't doing that even though do have Mailman 3.3.3 running
>>> like you said.
>>> If you have Curl installed, can you send me the output of:
>>> $ curl -u <user>:<pass> http://localhost:8001/3.1/members?count=5&page=1
>> This is the output you asked for (it's the same you can see when you try
>> to interact with one list):
>>
>> /usr/local/mailman3 # curl -u XXXXXX:XXXXXX
>> http://localhost:8001/3.1/members?count=5&page=1
>> /usr/local/mailman3 # <html>
>> <head>
>> <title>Internal Server Error</title>
>> </head>
>> <body>
>> <h1><p>Internal Server Error</p></h1>
>>
>> </body>
>> </html>
>>
>> No log entry has been produced...
> This is weird, if you have working Core, then there should be *some* json returned
> from the above command. Do you have the Gunicorn running?
I have the uwsgi approach running...
> What is the
> output of `ps -ef | grep mailman`?
none
but if I do an ps ax | grep mailman it shows
/usr/local/mailman3 # ps ax | grep mailman
26803 - IsJ 0:00.87 /usr/local/bin/python3.7 /usr/local/bin/master
--force -C /usr/local/mailman3/var/et
26834 - SJ 0:07.57 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26835 - IJ 0:05.84 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26836 - SJ 0:07.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26837 - SJ 0:08.74 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26838 - SJ 0:03.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26839 - SJ 0:07.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26840 - SJ 0:08.12 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26841 - SJ 0:09.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26842 - SJ 0:07.45 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26843 - IJ 0:00.95 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26844 - SJ 0:07.27 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26845 - SJ 0:07.69 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26859 - IJ 0:01.01 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
26860 - IJ 0:05.75 /usr/local/bin/python3.7 /usr/local/bin/runner -C
/usr/local/mailman3/var/etc/mailma
50153 - IsJ 0:00.16 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
50481 2 S+J 0:00.00 grep mailman
26808 1 SJ 0:02.09 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
26832 1 IJ 0:00.00 /usr/local/bin/uwsgi --ini
/usr/local/mailman3/uwsgi.ini
> Are you able to run `mailman members` command to list the members of a list?
Yes. All the commands are working as expected.
> Also, how did you actually install Mailman?
Using pip. Here is a detailled post of how I did put all together:
https://forums.FreeBSD.org/threads/mailman-3.61050/post-488128
Thanks for your support
>
> Abhilash.
>
>> TIA.
>>
>>
>>
>>
>>> It should ideally return an output that looks something like shown
>>> here[1]. You
>>> can put the username/password of Core's API server in the above command.
>>> [1]:
>>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…
>>>
>>> Abhilash
>>>> I'm using sqlite as django database and mysql for mailman.
>>>>
>>>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal
>>>> Server Error:
>>>> /mailman3/mailman3/lists/name_and_domain.of.the.list
>>>> Traceback (most recent call last): File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 119, in __getattr__ return self._get(name) File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 86, in _get raise KeyError(key) KeyError:
>>>> 'subscription_mode' During handling of the above exception,
>>>> another exception occurred: Traceback (most recent call
>>>> last): File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py",
>>>> line 34, in inner response = get_response(request) File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>> line 115, in _get_response response =
>>>> self.process_exception_by_middleware(e, request) File
>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>> line 113, in _get_response response =
>>>> wrapped_callback(request, *callback_args, **callback_kwargs)
>>>> File
>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>> line 71, in view return self.dispatch(request, *args,
>>>> **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py",
>>>> line 74, in dispatch return super(MailingListView,
>>>> self).dispatch(request, *args, **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>> line 97, in dispatch return handler(request, *args,
>>>> **kwargs) File
>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py",
>>>> line 295, in get member.subscription_mode == File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 124, in __getattr__ self.__class__.__name__, name))
>>>> AttributeError: 'Member' object has no attribute
>>>> 'subscription_mode' *********************** some info about
>>>> the installed versions via pip list: pip list | grep django
>>>> django-allauth 0.44.0
>>>> django-appconf 1.0.4
>>>> django-compressor 2.4
>>>> django-extensions 3.1.0
>>>> django-gravatar2 1.4.4
>>>> django-haystack 3.0
>>>> django-mailman3 1.3.5
>>>> django-picklefield 3.0.1
>>>> django-q 1.3.4
>>>> djangorestframework 3.12.2 pip list | grep mailman
>>>> django-mailman3 1.3.5
>>>> mailman 3.3.3
>>>> mailman-hyperkitty 1.1.0
>>>> mailmanclient 3.3.2 pip list | grep postorius
>>>> postorius 1.3.4 On 6/2/21 11:12,
>>>> Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>>>>
>>>> I've just upgrade mailman 3 installation following Mr.
>>>> Sapiro advice: did a pip install --upgrade
>>>> django-mailman3 hyperkitty mailman mailmanclient
>>>> mailman-hyperkitty postorius I did a "python3 manage.py
>>>> migrate" after, too. And all seemed to run well. All the
>>>> lists showed in postorius via web, but when I try to
>>>> accesss into one of them the browser shows an error. In
>>>> the log you can see: *-*-*-*-*-*-* Traceback (most recent
>>>> call last): File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 119, in __getattr__ return self._get(name)
>>>> File
>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>> line 86, in _get raise KeyError(key) KeyError:
>>>> 'get_requests_count' .. (And after all the traceback
>>>> lines) AttributeError: 'MailingList' object has no
>>>> attribute 'get_requests_count' *-*-*-*-*-*-*-* The lists
>>>> seem to be distributing messeages well.. but I cannot
>>>> acces via web administration (django/postorius) Can
>>>> anyone point me in the right direction to solve this,
>>>> please? _______________________________________________
>>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send
>>>> an email to mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>
>>>>
>>>> _______________________________________________ Mailman-users
>>>> mailing list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an
>>>> email to mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>
>>>>
>>>> _______________________________________________ Mailman-users mailing
>>>> list -- mailman-users(a)mailman3.org
>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an email to
>>>> mailman-users-leave(a)mailman3.org
>>>> <mailto:mailman-users-leave@mailman3.org>
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>
>> _______________________________________________
>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>
5 years
[MM3-users] Re: Hyperkitty CPU usage
by Abhilash Raj
On Sat, Apr 27, 2019, at 6:22 PM, Alain Kohli wrote:
> I'm running a custom image which is based on an older version of the one
> here: https://github.com/maxking/docker-mailman. I attached it below.
> But I separated postorius and hyperkitty, so hyperkitty is running in
> its own container. I'm deploying the image with a plain 'docker run'
> behind nginx. I made fulltext_index persistent now, but it didn't get
> populated with anything yet. I don't really have an error traceback
> because there is never an error thrown. The only thing with some content
> is uwsgi-error.log, which you can find below. I'm also still getting the
> "A string literal cannot contain NUL (0x00) characters." messages. I
> also noticed that it takes incredibly long for the webinterface to load
> (several minutes) even though there doesn't seem to be any process
> consuming notable resources apart from the minutely job.
>
> Funnily enough, I have the exact same image deployed on a second server
> as well for testing. On that one everything works fine. The only
> difference is that on the problematic one I have a lot more mailing
> lists/archives and that I imported them from mailman2. Could something
> have gone wrong during the import? I used the regular hyperkitty_import
> command.
Yes, this is because `whoosh`, the library set by default to run fulltext
indexing is a pure python implementation and quite slow in busy lists.
We do support more backends though, see [1] for a list of all the supported
search backends. Something like Xapian(C++) or Elasticsearch/Solr(Java)
should be much better in terms of performance.
[1]: https://django-haystack.readthedocs.io/en/master/backend_support.html
>
> uwsgi-error.log:
>
> *** Starting uWSGI 2.0.18 (64bit) on [Sat Apr 27 22:50:17 2019] ***
> compiled with version: 6.4.0 on 27 April 2019 22:48:42
> os: Linux-4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19)
> nodename: hyperkitty.docker
> machine: x86_64
> clock source: unix
> detected number of CPU cores: 4
> current working directory: /home/hyperkitty
> detected binary path: /usr/local/bin/uwsgi
> !!! no internal routing support, rebuild with pcre support !!!
> setgid() to 82
> setuid() to 82
> chdir() to /home/hyperkitty
> your memory page size is 4096 bytes
> detected max file descriptor number: 1048576
> lock engine: pthread robust mutexes
> thunder lock: disabled (you can enable it with --thunder-lock)
> uwsgi socket 0 bound to TCP address 0.0.0.0:8081 fd 8
> uwsgi socket 1 bound to TCP address 0.0.0.0:8080 fd 9
> Python version: 3.6.8 (default, Jan 30 2019, 23:54:38) [GCC 6.4.0]
> Python main interpreter initialized at 0x55dfaa41c980
> python threads support enabled
> your server socket listen backlog is limited to 100 connections
> your mercy for graceful operations on workers is 60 seconds
> [uwsgi-cron] command "./manage.py runjobs minutely" registered as
> cron task
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" registered
> as cron task
> [uwsgi-cron] command "./manage.py runjobs hourly" registered as cron
> task
> [uwsgi-cron] command "./manage.py runjobs daily" registered as cron task
> [uwsgi-cron] command "./manage.py runjobs monthly" registered as
> cron task
> [uwsgi-cron] command "./manage.py runjobs weekly" registered as cron
> task
> [uwsgi-cron] command "./manage.py runjobs yearly" registered as cron
> task
> mapped 208576 bytes (203 KB) for 4 cores
> *** Operational MODE: threaded ***
> WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter
> 0x55dfaa41c980 pid: 1 (default app)
> *** uWSGI is running in multiple interpreter mode ***
> spawned uWSGI master process (pid: 1)
> spawned uWSGI worker 1 (pid: 40, cores: 4)
> Sat Apr 27 22:50:18 2019 - [uwsgi-cron] running "./manage.py runjobs
> minutely" (pid 45)
> [uwsgi-daemons] spawning "./manage.py qcluster" (uid: 82 gid: 82)
> 22:50:21 [Q] INFO Q Cluster-47 starting.
> 22:50:21 [Q] INFO Process-1:1 ready for work at 59
> 22:50:21 [Q] INFO Process-1:2 ready for work at 60
> 22:50:21 [Q] INFO Process-1:3 ready for work at 61
> 22:50:21 [Q] INFO Process-1:4 ready for work at 62
> 22:50:21 [Q] INFO Process-1:5 monitoring at 63
> 22:50:21 [Q] INFO Process-1 guarding cluster at 58
> 22:50:21 [Q] INFO Process-1:6 pushing tasks at 64
> 22:50:21 [Q] INFO Q Cluster-47 running.
> 22:59:31 [Q] INFO Enqueued 3403
> 22:59:31 [Q] INFO Process-1:1 processing [update_from_mailman]
> 22:59:33 [Q] INFO Processed [update_from_mailman]
> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> quarter_hourly" (pid 73)
> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> hourly" (pid 74)
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
> with pid 73 exited after 64 second(s)
> 23:01:28 [Q] INFO Enqueued 3404
> 23:01:29 [Q] INFO Process-1:2 processing
> [rebuild_mailinglist_cache_recent]
> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
> 74 exited after 91 second(s)
> Sat Apr 27 23:01:36 2019 - uwsgi_response_write_body_do(): Broken
> pipe [core/writer.c line 341] during GET / (212.203.58.154)
> OSError: write error
> 23:01:36 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
> Sat Apr 27 23:15:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> quarter_hourly" (pid 88)
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
> with pid 88 exited after 4 second(s)
> 23:28:24 [Q] INFO Enqueued 3405
> 23:28:24 [Q] INFO Process-1:3 processing [update_from_mailman]
> 23:28:25 [Q] INFO Processed [update_from_mailman]
> Sat Apr 27 23:30:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> quarter_hourly" (pid 96)
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
> with pid 96 exited after 4 second(s)
> 23:44:40 [Q] INFO Enqueued 3406
> 23:44:40 [Q] INFO Process-1:4 processing [update_from_mailman]
> 23:44:41 [Q] INFO Processed [update_from_mailman]
> Sat Apr 27 23:45:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> quarter_hourly" (pid 104)
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
> with pid 104 exited after 4 second(s)
> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> quarter_hourly" (pid 113)
> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> hourly" (pid 114)
> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> daily" (pid 115)
> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
> weekly" (pid 116)
> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
> with pid 113 exited after 55 second(s)
> [uwsgi-cron] command "./manage.py runjobs weekly" running with pid
> 116 exited after 55 second(s)
> 00:01:36 [Q] INFO Enqueued 3407
> 00:01:36 [Q] INFO Process-1:1 processing
> [rebuild_mailinglist_cache_recent]
> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
> 114 exited after 99 second(s)
> 00:01:50 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
> 00:04:52 [Q] INFO Enqueued 3408
> 00:04:52 [Q] INFO Process-1:2 processing [update_from_mailman]
> 00:04:54 [Q] INFO Processed [update_from_mailman]
>
> Dockerfile:
>
> FROM python:3.6-alpine3.7 # Add startup script to container COPY
> assets/docker-entrypoint.sh /usr/local/bin/ # Install packages and
> dependencies for hyperkitty and add user for executing apps. # It's
> important that the user has the UID/GID 82 so nginx can access the
> files. RUN set -ex \&& apk add --no-cache --virtual .build-deps gcc
> libc-dev linux-headers git \postgresql-dev \&& apk add --no-cache
> --virtual .mailman-rundeps bash sassc mailcap \postgresql-client
> curl \&& pip install -U django==2.2 \&& pip install
> git+https://gitlab.com/eestec/mailmanclient
>
> \git+https://gitlab.com/mailman/hyperkitty@c9fa4d4bfc295438d3e01cd93090064d004cf44d
> \git+https://gitlab.com/eestec/django-mailman3 \whoosh \uwsgi
> \psycopg2 \dj-database-url \typing \&& apk del .build-deps \&&
> addgroup -S -g 82 hyperkitty \&& adduser -S -u 82 -G hyperkitty
> hyperkitty \&& chmod u+x /usr/local/bin/docker-entrypoint.sh# Add
> needed files for uwsgi server + settings for django COPY
> assets/__init__.py /home/hyperkittyCOPY assets/manage.py
> /home/hyperkittyCOPY assets/urls.py /home/hyperkittyCOPY
> assets/wsgi.py /home/hyperkittyCOPY assets/uwsgi.ini
> /home/hyperkittyCOPY assets/settings.py /home/hyperkitty# Change
> ownership for uwsgi+django files and set execution rights for
> management script RUN chown -R hyperkitty /home/hyperkitty && chmod
> u+x /home/hyperkitty/manage.py# Make sure we are in the correct
> working dir WORKDIR /home/hyperkittyEXPOSE 8080 8081# Use stop
> signal for uwsgi server STOPSIGNAL SIGINTENTRYPOINT
> ["docker-entrypoint.sh"]CMD ["uwsgi", "--ini",
> "/home/hyperkitty/uwsgi.ini"]
>
> On 4/27/19 7:58 PM, Abhilash Raj wrote:
> > On Sat, Apr 27, 2019, at 9:40 AM, Alain Kohli wrote:
> >> I have run "python manage.py rebuild_index" before, doesn't that do
> >> clear_index as well? Apart from that, I run hyperkitty in a docker
> >> container and didn't know fulltext_index should be persistent, so that
> >> got deleted after every version update for sure.
> > Which images are you using and how are you deploying them?
> >
> > You should persist fulltext_index, yes, and possibly logs if you need
> > them for debugging later.
> >
> > Can you paste the entire error traceback?
> >
> >>
> >> On 4/26/19 10:18 PM, Mark Sapiro wrote:
> >>> On 4/26/19 11:14 AM, Alain Kohli wrote:
> >>>> I see loads of "A string literal cannot contain NUL (0x00) characters."
> >>>> messages, but I haven't found missing messages in the archives yet. Not
> >>>> sure how that could be related, though. Apart from that I don't see
> >>>> anything unusual. The other jobs (quarter_hourly, hourly, etc.) seem to
> >>>> run and finish normally.
> >>> Did you upgrade from a Python 2.7 version of HyperKitty to a Python 3
> >>> version? The Haystack/Whoosh search engine databases are not compatible
> >>> between the two and "A string literal cannot contain NUL (0x00)
> >>> characters." is the symptom.
> >>>
> >>> You need to run 'python manage.py clear_index' or just remove all the
> >>> files from the directory defined as 'PATH' under HAYSTACK_CONNECTIONS in
> >>> your settings file (normally 'fulltext_index' in the same directory that
> >>> contains your settings.py.
> >>>
> >> _______________________________________________
> >> Mailman-users mailing list -- mailman-users(a)mailman3.org
> >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
> >>
>
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>
--
thanks,
Abhilash Raj (maxking)
6 years, 9 months
[MM3-users] Re: User settings triggers error
by Mark Dadgar
On Jun 16, 2020, at 11:47 AM, Mark Sapiro <mark(a)msapiro.net> wrote:
>> File "/usr/lib/python3/dist-packages/mailmanclient/restbase/connection.py" in call
>> 99. raise HTTPError(url, response.status, content, response, None)
>
> And gets a 500 from core.
>
>
>> During handling of the above exception (HTTP Error 500: b'A server error occurred. Please contact the administrator.'), another exception occurred:
>
>
> Which we aren't interested in.
>
> The next step is to look in core's mailman.log to see what the rest call
> was and the exception and hopefully traceback the caused the 500 response.
Here’s what’s logged during that error:
Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/mark(a)pdc-racing.net HTTP/1.1" 200 432
Jun 16 12:16:54 2020 (1326) REST request handler error:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper
rtn = function(*args, **kws)
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__
return super().__call__(environ, start_response)
File "falcon/api.py", line 232, in falcon.api.API.__call__
File "falcon/api.py", line 229, in falcon.api.API.__call__
File "falcon/api.py", line 582, in falcon.api.API._get_responder
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 131, in find
attribute = getattr(resource, name, MISSING)
File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user
return user_manager.get_user_by_id(user_id)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3/dist-packages/mailman/model/usermanager.py", line 94, in get_user_by_id
if users.count() == 0:
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count
return self.from_self(col).scalar()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar
ret = self.one()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one
ret = self.one_or_none()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none
ret = list(self)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__
return self._execute_and_instances(context)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances
result = conn.execute(querycontext.statement, self._params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute
return meth(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement
ret = self._execute_context(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context
self._handle_dbapi_exception(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
[SQL: SELECT count(*) AS count_1
FROM (SELECT "user".password AS user_password, "user".id AS user_id, "user".display_name AS user_display_name, "user"._user_id AS user__user_id, "user"._created_on AS user__created_on, "user".is_server_owner AS user_is_server_owner, "user"._preferred_address_id AS user__preferred_address_id, "user".preferences_id AS user_preferences_id
FROM "user"
WHERE "user"._user_id = %(user_id_1)s) AS anon_1]
[parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}]
(Background on this error at: http://sqlalche.me/e/f405)
Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/05dcbeb4b78445eb96f86f9e4b7ab6cb/addresses HTTP/1.1" 500 59
Jun 16 12:16:54 2020 (1326) REST request handler error:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper
rtn = function(*args, **kws)
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__
return super().__call__(environ, start_response)
File "falcon/api.py", line 232, in falcon.api.API.__call__
File "falcon/api.py", line 229, in falcon.api.API.__call__
File "falcon/api.py", line 582, in falcon.api.API._get_responder
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 131, in find
attribute = getattr(resource, name, MISSING)
File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user
return user_manager.get_user_by_id(user_id)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3/dist-packages/mailman/model/usermanager.py", line 94, in get_user_by_id
if users.count() == 0:
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count
return self.from_self(col).scalar()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar
ret = self.one()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one
ret = self.one_or_none()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none
ret = list(self)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__
return self._execute_and_instances(context)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances
result = conn.execute(querycontext.statement, self._params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute
return meth(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement
ret = self._execute_context(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context
self._handle_dbapi_exception(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
[SQL: SELECT count(*) AS count_1
FROM (SELECT "user".password AS user_password, "user".id AS user_id, "user".display_name AS user_display_name, "user"._user_id AS user__user_id, "user"._created_on AS user__created_on, "user".is_server_owner AS user_is_server_owner, "user"._preferred_address_id AS user__preferred_address_id, "user".preferences_id AS user_preferences_id
FROM "user"
WHERE "user"._user_id = %(user_id_1)s) AS anon_1]
[parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}]
(Background on this error at: http://sqlalche.me/e/f405)
Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/05dcbeb4b78445eb96f86f9e4b7ab6cb/addresses HTTP/1.1" 500 59
Jun 16 12:16:54 2020 (1326) REST request handler error:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
psycopg2.errors.UndefinedFunction: operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/lib/python3.8/wsgiref/handlers.py", line 137, in run
self.result = application(self.environ, self.start_response)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 50, in wrapper
rtn = function(*args, **kws)
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 218, in __call__
return super().__call__(environ, start_response)
File "falcon/api.py", line 232, in falcon.api.API.__call__
File "falcon/api.py", line 229, in falcon.api.API.__call__
File "falcon/api.py", line 582, in falcon.api.API._get_responder
File "/usr/lib/python3/dist-packages/mailman/rest/wsgiapp.py", line 131, in find
attribute = getattr(resource, name, MISSING)
File "/usr/lib/python3/dist-packages/mailman/rest/users.py", line 203, in _user
return user_manager.get_user_by_id(user_id)
File "/usr/lib/python3/dist-packages/mailman/database/transaction.py", line 85, in wrapper
return function(args[0], config.db.store, *args[1:], **kws)
File "/usr/lib/python3/dist-packages/mailman/model/usermanager.py", line 94, in get_user_by_id
if users.count() == 0:
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3630, in count
return self.from_self(col).scalar()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3355, in scalar
ret = self.one()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3325, in one
ret = self.one_or_none()
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3294, in one_or_none
ret = list(self)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3367, in __iter__
return self._execute_and_instances(context)
File "/usr/lib/python3/dist-packages/sqlalchemy/orm/query.py", line 3392, in _execute_and_instances
result = conn.execute(querycontext.statement, self._params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 982, in execute
return meth(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/sql/elements.py", line 287, in _execute_on_connection
return connection._execute_clauseelement(self, multiparams, params)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1095, in _execute_clauseelement
ret = self._execute_context(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1249, in _execute_context
self._handle_dbapi_exception(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1476, in _handle_dbapi_exception
util.raise_from_cause(sqlalchemy_exception, exc_info)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 398, in raise_from_cause
reraise(type(exception), exception, tb=exc_tb, cause=cause)
File "/usr/lib/python3/dist-packages/sqlalchemy/util/compat.py", line 152, in reraise
raise value.with_traceback(tb)
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1245, in _execute_context
self.dialect.do_execute(
File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 581, in do_execute
cursor.execute(statement, parameters)
sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedFunction) operator does not exist: text = uuid
LINE 4: WHERE "user"._user_id = '05dcbeb4-b784-45eb-96f8-6f9e4b7ab6c...
^
HINT: No operator matches the given name and argument types. You might need to add explicit type casts.
[SQL: SELECT count(*) AS count_1
FROM (SELECT "user".password AS user_password, "user".id AS user_id, "user".display_name AS user_display_name, "user"._user_id AS user__user_id, "user"._created_on AS user__created_on, "user".is_server_owner AS user_is_server_owner, "user"._preferred_address_id AS user__preferred_address_id, "user".preferences_id AS user_preferences_id
FROM "user"
WHERE "user"._user_id = %(user_id_1)s) AS anon_1]
[parameters: {'user_id_1': UUID('05dcbeb4-b784-45eb-96f8-6f9e4b7ab6cb')}]
(Background on this error at: http://sqlalche.me/e/f405)
Jun 16 12:16:54 2020 (1326) 127.0.0.1 - - "GET /3.1/users/05dcbeb4b78445eb96f86f9e4b7ab6cb/addresses HTTP/1.1" 500 59
- Mark
-----
mark(a)pdc-racing.net | 408-348-2878
5 years, 8 months
[MM3-users] Re: Hyperkitty CPU usage
by Alain Kohli
Well, I understand that it might take a while, but the process is
running for over 200h now, I doubt it can really take _that_ long if
everything is working properly. Especially because the rebuild_index
command is only taking a few hours at most, doesn't that essentially do
the same?
We have ~700k messages in ~300 mailing lists in case that helps you
estimate how long it could take. I can take a look at alternative
backends, though.
On 5/7/19 4:32 PM, Abhilash Raj wrote:
> On Sat, Apr 27, 2019, at 6:22 PM, Alain Kohli wrote:
>> I'm running a custom image which is based on an older version of the one
>> here: https://github.com/maxking/docker-mailman. I attached it below.
>> But I separated postorius and hyperkitty, so hyperkitty is running in
>> its own container. I'm deploying the image with a plain 'docker run'
>> behind nginx. I made fulltext_index persistent now, but it didn't get
>> populated with anything yet. I don't really have an error traceback
>> because there is never an error thrown. The only thing with some content
>> is uwsgi-error.log, which you can find below. I'm also still getting the
>> "A string literal cannot contain NUL (0x00) characters." messages. I
>> also noticed that it takes incredibly long for the webinterface to load
>> (several minutes) even though there doesn't seem to be any process
>> consuming notable resources apart from the minutely job.
>>
>> Funnily enough, I have the exact same image deployed on a second server
>> as well for testing. On that one everything works fine. The only
>> difference is that on the problematic one I have a lot more mailing
>> lists/archives and that I imported them from mailman2. Could something
>> have gone wrong during the import? I used the regular hyperkitty_import
>> command.
> Yes, this is because `whoosh`, the library set by default to run fulltext
> indexing is a pure python implementation and quite slow in busy lists.
>
> We do support more backends though, see [1] for a list of all the supported
> search backends. Something like Xapian(C++) or Elasticsearch/Solr(Java)
> should be much better in terms of performance.
>
> [1]: https://django-haystack.readthedocs.io/en/master/backend_support.html
>
>> uwsgi-error.log:
>>
>> *** Starting uWSGI 2.0.18 (64bit) on [Sat Apr 27 22:50:17 2019] ***
>> compiled with version: 6.4.0 on 27 April 2019 22:48:42
>> os: Linux-4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19)
>> nodename: hyperkitty.docker
>> machine: x86_64
>> clock source: unix
>> detected number of CPU cores: 4
>> current working directory: /home/hyperkitty
>> detected binary path: /usr/local/bin/uwsgi
>> !!! no internal routing support, rebuild with pcre support !!!
>> setgid() to 82
>> setuid() to 82
>> chdir() to /home/hyperkitty
>> your memory page size is 4096 bytes
>> detected max file descriptor number: 1048576
>> lock engine: pthread robust mutexes
>> thunder lock: disabled (you can enable it with --thunder-lock)
>> uwsgi socket 0 bound to TCP address 0.0.0.0:8081 fd 8
>> uwsgi socket 1 bound to TCP address 0.0.0.0:8080 fd 9
>> Python version: 3.6.8 (default, Jan 30 2019, 23:54:38) [GCC 6.4.0]
>> Python main interpreter initialized at 0x55dfaa41c980
>> python threads support enabled
>> your server socket listen backlog is limited to 100 connections
>> your mercy for graceful operations on workers is 60 seconds
>> [uwsgi-cron] command "./manage.py runjobs minutely" registered as
>> cron task
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" registered
>> as cron task
>> [uwsgi-cron] command "./manage.py runjobs hourly" registered as cron
>> task
>> [uwsgi-cron] command "./manage.py runjobs daily" registered as cron task
>> [uwsgi-cron] command "./manage.py runjobs monthly" registered as
>> cron task
>> [uwsgi-cron] command "./manage.py runjobs weekly" registered as cron
>> task
>> [uwsgi-cron] command "./manage.py runjobs yearly" registered as cron
>> task
>> mapped 208576 bytes (203 KB) for 4 cores
>> *** Operational MODE: threaded ***
>> WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter
>> 0x55dfaa41c980 pid: 1 (default app)
>> *** uWSGI is running in multiple interpreter mode ***
>> spawned uWSGI master process (pid: 1)
>> spawned uWSGI worker 1 (pid: 40, cores: 4)
>> Sat Apr 27 22:50:18 2019 - [uwsgi-cron] running "./manage.py runjobs
>> minutely" (pid 45)
>> [uwsgi-daemons] spawning "./manage.py qcluster" (uid: 82 gid: 82)
>> 22:50:21 [Q] INFO Q Cluster-47 starting.
>> 22:50:21 [Q] INFO Process-1:1 ready for work at 59
>> 22:50:21 [Q] INFO Process-1:2 ready for work at 60
>> 22:50:21 [Q] INFO Process-1:3 ready for work at 61
>> 22:50:21 [Q] INFO Process-1:4 ready for work at 62
>> 22:50:21 [Q] INFO Process-1:5 monitoring at 63
>> 22:50:21 [Q] INFO Process-1 guarding cluster at 58
>> 22:50:21 [Q] INFO Process-1:6 pushing tasks at 64
>> 22:50:21 [Q] INFO Q Cluster-47 running.
>> 22:59:31 [Q] INFO Enqueued 3403
>> 22:59:31 [Q] INFO Process-1:1 processing [update_from_mailman]
>> 22:59:33 [Q] INFO Processed [update_from_mailman]
>> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> quarter_hourly" (pid 73)
>> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> hourly" (pid 74)
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>> with pid 73 exited after 64 second(s)
>> 23:01:28 [Q] INFO Enqueued 3404
>> 23:01:29 [Q] INFO Process-1:2 processing
>> [rebuild_mailinglist_cache_recent]
>> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
>> 74 exited after 91 second(s)
>> Sat Apr 27 23:01:36 2019 - uwsgi_response_write_body_do(): Broken
>> pipe [core/writer.c line 341] during GET / (212.203.58.154)
>> OSError: write error
>> 23:01:36 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
>> Sat Apr 27 23:15:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> quarter_hourly" (pid 88)
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>> with pid 88 exited after 4 second(s)
>> 23:28:24 [Q] INFO Enqueued 3405
>> 23:28:24 [Q] INFO Process-1:3 processing [update_from_mailman]
>> 23:28:25 [Q] INFO Processed [update_from_mailman]
>> Sat Apr 27 23:30:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> quarter_hourly" (pid 96)
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>> with pid 96 exited after 4 second(s)
>> 23:44:40 [Q] INFO Enqueued 3406
>> 23:44:40 [Q] INFO Process-1:4 processing [update_from_mailman]
>> 23:44:41 [Q] INFO Processed [update_from_mailman]
>> Sat Apr 27 23:45:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> quarter_hourly" (pid 104)
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>> with pid 104 exited after 4 second(s)
>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> quarter_hourly" (pid 113)
>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> hourly" (pid 114)
>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> daily" (pid 115)
>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py runjobs
>> weekly" (pid 116)
>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>> with pid 113 exited after 55 second(s)
>> [uwsgi-cron] command "./manage.py runjobs weekly" running with pid
>> 116 exited after 55 second(s)
>> 00:01:36 [Q] INFO Enqueued 3407
>> 00:01:36 [Q] INFO Process-1:1 processing
>> [rebuild_mailinglist_cache_recent]
>> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
>> 114 exited after 99 second(s)
>> 00:01:50 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
>> 00:04:52 [Q] INFO Enqueued 3408
>> 00:04:52 [Q] INFO Process-1:2 processing [update_from_mailman]
>> 00:04:54 [Q] INFO Processed [update_from_mailman]
>>
>> Dockerfile:
>>
>> FROM python:3.6-alpine3.7 # Add startup script to container COPY
>> assets/docker-entrypoint.sh /usr/local/bin/ # Install packages and
>> dependencies for hyperkitty and add user for executing apps. # It's
>> important that the user has the UID/GID 82 so nginx can access the
>> files. RUN set -ex \&& apk add --no-cache --virtual .build-deps gcc
>> libc-dev linux-headers git \postgresql-dev \&& apk add --no-cache
>> --virtual .mailman-rundeps bash sassc mailcap \postgresql-client
>> curl \&& pip install -U django==2.2 \&& pip install
>> git+https://gitlab.com/eestec/mailmanclient
>>
>> \git+https://gitlab.com/mailman/hyperkitty@c9fa4d4bfc295438d3e01cd93090064d004cf44d
>> \git+https://gitlab.com/eestec/django-mailman3 \whoosh \uwsgi
>> \psycopg2 \dj-database-url \typing \&& apk del .build-deps \&&
>> addgroup -S -g 82 hyperkitty \&& adduser -S -u 82 -G hyperkitty
>> hyperkitty \&& chmod u+x /usr/local/bin/docker-entrypoint.sh# Add
>> needed files for uwsgi server + settings for django COPY
>> assets/__init__.py /home/hyperkittyCOPY assets/manage.py
>> /home/hyperkittyCOPY assets/urls.py /home/hyperkittyCOPY
>> assets/wsgi.py /home/hyperkittyCOPY assets/uwsgi.ini
>> /home/hyperkittyCOPY assets/settings.py /home/hyperkitty# Change
>> ownership for uwsgi+django files and set execution rights for
>> management script RUN chown -R hyperkitty /home/hyperkitty && chmod
>> u+x /home/hyperkitty/manage.py# Make sure we are in the correct
>> working dir WORKDIR /home/hyperkittyEXPOSE 8080 8081# Use stop
>> signal for uwsgi server STOPSIGNAL SIGINTENTRYPOINT
>> ["docker-entrypoint.sh"]CMD ["uwsgi", "--ini",
>> "/home/hyperkitty/uwsgi.ini"]
>>
>> On 4/27/19 7:58 PM, Abhilash Raj wrote:
>>> On Sat, Apr 27, 2019, at 9:40 AM, Alain Kohli wrote:
>>>> I have run "python manage.py rebuild_index" before, doesn't that do
>>>> clear_index as well? Apart from that, I run hyperkitty in a docker
>>>> container and didn't know fulltext_index should be persistent, so that
>>>> got deleted after every version update for sure.
>>> Which images are you using and how are you deploying them?
>>>
>>> You should persist fulltext_index, yes, and possibly logs if you need
>>> them for debugging later.
>>>
>>> Can you paste the entire error traceback?
>>>
>>>> On 4/26/19 10:18 PM, Mark Sapiro wrote:
>>>>> On 4/26/19 11:14 AM, Alain Kohli wrote:
>>>>>> I see loads of "A string literal cannot contain NUL (0x00) characters."
>>>>>> messages, but I haven't found missing messages in the archives yet. Not
>>>>>> sure how that could be related, though. Apart from that I don't see
>>>>>> anything unusual. The other jobs (quarter_hourly, hourly, etc.) seem to
>>>>>> run and finish normally.
>>>>> Did you upgrade from a Python 2.7 version of HyperKitty to a Python 3
>>>>> version? The Haystack/Whoosh search engine databases are not compatible
>>>>> between the two and "A string literal cannot contain NUL (0x00)
>>>>> characters." is the symptom.
>>>>>
>>>>> You need to run 'python manage.py clear_index' or just remove all the
>>>>> files from the directory defined as 'PATH' under HAYSTACK_CONNECTIONS in
>>>>> your settings file (normally 'fulltext_index' in the same directory that
>>>>> contains your settings.py.
>>>>>
>>>> _______________________________________________
>>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>>
>> _______________________________________________
>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>
6 years, 9 months
[MM3-users] seems solved (was: Re: error changed after restart)
by Guillermo Hernandez (Oldno7)
On 7/2/21 19:33, Guillermo Hernandez (Oldno7) via Mailman-users wrote:
> On 7/2/21 19:04, Abhilash Raj wrote:
Well... I did reinstall all mailman relationed apps with a
pip install --upgrade --force-reinstall --no-deps --no-cache-dir
django-mailman3 mailman mailman-hyperkitty mailmanclient
Restarted thee apache24 server...
Aaaaaand closed de admin session and reopened it... (just for a "what
if" sensation).
I can not tell what have been the solution here, but now I can access
the administrative pages and attend de pending subscriptions and discard
retained messages.
Thanks Abhilash and Mark for your support.
>>
>> On Sun, Feb 7, 2021, at 1:07 AM, Guillermo Hernandez (Oldno7) via
>> Mailman-users wrote:
>>> On 6/2/21 21:19, Abhilash Raj wrote:
>>>>
>>>> On Sat, Feb 6, 2021 at 19:44, Guillermo Hernandez (Oldno7) via
>>>> Mailman-users <mailman-users(a)mailman3.org> wrote:
>>>>> On 6/2/21 18:08, Abhilash Raj wrote:
>>>>>
>>>>> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7)
>>>>> via
>>>>> Mailman-users wrote:
>>>>>
>>>>> I restarted de server and the error changed. Now the log
>>>>> shows "KeyError: 'subscription_mode'":
>>>>>
>>>>> Did you also restart Mailman Core after the upgrade?
>>>>>
>>>>> Yes, indeed: I stopped mailman core and all the processes related.
>>>>> Did the upgrades. Started all again. Find the errors in the web user
>>>>> interface. Stopped all again. Looked for errors in the log. Restarted
>>>>> the complete server. Found the second error that this second mail is
>>>>> about to. It happens when, in the main page that shows all the lists
>>>>> you click to see one of them. It seems to me that it has been
>>>>> database structure changes in django that the upgrade is not aware...
>>>>> but it's a very long shot from my side.
>>>> `subscription_mode` was added in Mailman Core 3.3.2 and it is actually
>>>> a derived atrribute and not stored in Database. Mailman's API
>>>> should be
>>>> returning this attribute for each Member, but for some reason it seems
>>>> to me like it isn't doing that even though do have Mailman 3.3.3
>>>> running
>>>> like you said.
>>>> If you have Curl installed, can you send me the output of:
>>>> $ curl -u <user>:<pass>
>>>> http://localhost:8001/3.1/members?count=5&page=1
>>> This is the output you asked for (it's the same you can see when you
>>> try
>>> to interact with one list):
>>>
>>> /usr/local/mailman3 # curl -u XXXXXX:XXXXXX
>>> http://localhost:8001/3.1/members?count=5&page=1
>>> /usr/local/mailman3 # <html>
>>> <head>
>>> <title>Internal Server Error</title>
>>> </head>
>>> <body>
>>> <h1><p>Internal Server Error</p></h1>
>>>
>>> </body>
>>> </html>
>>>
>>> No log entry has been produced...
>> This is weird, if you have working Core, then there should be *some*
>> json returned
>> from the above command. Do you have the Gunicorn running?
> I have the uwsgi approach running...
>> What is the
>> output of `ps -ef | grep mailman`?
>
> none
>
> but if I do an ps ax | grep mailman it shows
>
> /usr/local/mailman3 # ps ax | grep mailman
> 26803 - IsJ 0:00.87 /usr/local/bin/python3.7 /usr/local/bin/master
> --force -C /usr/local/mailman3/var/et
> 26834 - SJ 0:07.57 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26835 - IJ 0:05.84 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26836 - SJ 0:07.16 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26837 - SJ 0:08.74 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26838 - SJ 0:03.16 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26839 - SJ 0:07.07 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26840 - SJ 0:08.12 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26841 - SJ 0:09.07 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26842 - SJ 0:07.45 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26843 - IJ 0:00.95 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26844 - SJ 0:07.27 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26845 - SJ 0:07.69 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26859 - IJ 0:01.01 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 26860 - IJ 0:05.75 /usr/local/bin/python3.7 /usr/local/bin/runner
> -C /usr/local/mailman3/var/etc/mailma
> 50153 - IsJ 0:00.16 /usr/local/bin/uwsgi --ini
> /usr/local/mailman3/uwsgi.ini
> 50481 2 S+J 0:00.00 grep mailman
> 26808 1 SJ 0:02.09 /usr/local/bin/uwsgi --ini
> /usr/local/mailman3/uwsgi.ini
> 26832 1 IJ 0:00.00 /usr/local/bin/uwsgi --ini
> /usr/local/mailman3/uwsgi.ini
>
>> Are you able to run `mailman members` command to list the members of
>> a list?
>
> Yes. All the commands are working as expected.
>
>> Also, how did you actually install Mailman?
>
> Using pip. Here is a detailled post of how I did put all together:
>
> https://forums.FreeBSD.org/threads/mailman-3.61050/post-488128
>
> Thanks for your support
>
>>
>> Abhilash.
>>
>>> TIA.
>>>
>>>
>>>
>>>
>>>> It should ideally return an output that looks something like shown
>>>> here[1]. You
>>>> can put the username/password of Core's API server in the above
>>>> command.
>>>> [1]:
>>>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/…
>>>>
>>>>
>>>> Abhilash
>>>>> I'm using sqlite as django database and mysql for mailman.
>>>>>
>>>>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal
>>>>> Server Error:
>>>>> /mailman3/mailman3/lists/name_and_domain.of.the.list
>>>>> Traceback (most recent call last): File
>>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>>>
>>>>> line 119, in __getattr__ return self._get(name) File
>>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>>>
>>>>> line 86, in _get raise KeyError(key) KeyError:
>>>>> 'subscription_mode' During handling of the above exception,
>>>>> another exception occurred: Traceback (most recent call
>>>>> last): File
>>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py",
>>>>> line 34, in inner response = get_response(request)
>>>>> File
>>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>>>
>>>>> line 115, in _get_response response =
>>>>> self.process_exception_by_middleware(e, request) File
>>>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py",
>>>>>
>>>>> line 113, in _get_response response =
>>>>> wrapped_callback(request, *callback_args, **callback_kwargs)
>>>>> File
>>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>>>
>>>>> line 71, in view return self.dispatch(request, *args,
>>>>> **kwargs) File
>>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py",
>>>>> line 74, in dispatch return super(MailingListView,
>>>>> self).dispatch(request, *args, **kwargs) File
>>>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py",
>>>>>
>>>>> line 97, in dispatch return handler(request, *args,
>>>>> **kwargs) File
>>>>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py",
>>>>> line 295, in get member.subscription_mode == File
>>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>>>
>>>>> line 124, in __getattr__ self.__class__.__name__, name))
>>>>> AttributeError: 'Member' object has no attribute
>>>>> 'subscription_mode' *********************** some info about
>>>>> the installed versions via pip list: pip list | grep django
>>>>> django-allauth 0.44.0
>>>>> django-appconf 1.0.4
>>>>> django-compressor 2.4
>>>>> django-extensions 3.1.0
>>>>> django-gravatar2 1.4.4
>>>>> django-haystack 3.0
>>>>> django-mailman3 1.3.5
>>>>> django-picklefield 3.0.1
>>>>> django-q 1.3.4
>>>>> djangorestframework 3.12.2 pip list | grep mailman
>>>>> django-mailman3 1.3.5
>>>>> mailman 3.3.3
>>>>> mailman-hyperkitty 1.1.0
>>>>> mailmanclient 3.3.2 pip list | grep
>>>>> postorius
>>>>> postorius 1.3.4 On 6/2/21 11:12,
>>>>> Guillermo Hernandez (Oldno7) via Mailman-users wrote:
>>>>>
>>>>> I've just upgrade mailman 3 installation following Mr.
>>>>> Sapiro advice: did a pip install --upgrade
>>>>> django-mailman3 hyperkitty mailman mailmanclient
>>>>> mailman-hyperkitty postorius I did a "python3 manage.py
>>>>> migrate" after, too. And all seemed to run well. All the
>>>>> lists showed in postorius via web, but when I try to
>>>>> accesss into one of them the browser shows an error. In
>>>>> the log you can see: *-*-*-*-*-*-* Traceback (most
>>>>> recent
>>>>> call last): File
>>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>>>
>>>>> line 119, in __getattr__ return self._get(name)
>>>>> File
>>>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py",
>>>>>
>>>>> line 86, in _get raise KeyError(key) KeyError:
>>>>> 'get_requests_count' .. (And after all the traceback
>>>>> lines) AttributeError: 'MailingList' object has no
>>>>> attribute 'get_requests_count' *-*-*-*-*-*-*-* The lists
>>>>> seem to be distributing messeages well.. but I cannot
>>>>> acces via web administration (django/postorius) Can
>>>>> anyone point me in the right direction to solve this,
>>>>> please? _______________________________________________
>>>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send
>>>>> an email to mailman-users-leave(a)mailman3.org
>>>>> <mailto:mailman-users-leave@mailman3.org>
>>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailman-users
>>>>> mailing list -- mailman-users(a)mailman3.org
>>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an
>>>>> email to mailman-users-leave(a)mailman3.org
>>>>> <mailto:mailman-users-leave@mailman3.org>
>>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>>
>>>>>
>>>>> _______________________________________________ Mailman-users mailing
>>>>> list -- mailman-users(a)mailman3.org
>>>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an email to
>>>>> mailman-users-leave(a)mailman3.org
>>>>> <mailto:mailman-users-leave@mailman3.org>
>>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/>
>>>>>
>>>
>>> _______________________________________________
>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>
> _______________________________________________
> Mailman-users mailing list -- mailman-users(a)mailman3.org
> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>
5 years
[MM3-users] Re: Hyperkitty CPU usage
by Alain Kohli
I have not seen any improvement over time, so I switched the backend to
Xapian. That works like a charm now, I guess our lists were indeed just
too busy for whoosh.
On 5/7/19 5:15 PM, Alain Kohli wrote:
> Well, I understand that it might take a while, but the process is
> running for over 200h now, I doubt it can really take _that_ long if
> everything is working properly. Especially because the rebuild_index
> command is only taking a few hours at most, doesn't that essentially
> do the same?
>
> We have ~700k messages in ~300 mailing lists in case that helps you
> estimate how long it could take. I can take a look at alternative
> backends, though.
>
>
> On 5/7/19 4:32 PM, Abhilash Raj wrote:
>> On Sat, Apr 27, 2019, at 6:22 PM, Alain Kohli wrote:
>>> I'm running a custom image which is based on an older version of the
>>> one
>>> here: https://github.com/maxking/docker-mailman. I attached it below.
>>> But I separated postorius and hyperkitty, so hyperkitty is running in
>>> its own container. I'm deploying the image with a plain 'docker run'
>>> behind nginx. I made fulltext_index persistent now, but it didn't get
>>> populated with anything yet. I don't really have an error traceback
>>> because there is never an error thrown. The only thing with some
>>> content
>>> is uwsgi-error.log, which you can find below. I'm also still getting
>>> the
>>> "A string literal cannot contain NUL (0x00) characters." messages. I
>>> also noticed that it takes incredibly long for the webinterface to load
>>> (several minutes) even though there doesn't seem to be any process
>>> consuming notable resources apart from the minutely job.
>>>
>>> Funnily enough, I have the exact same image deployed on a second server
>>> as well for testing. On that one everything works fine. The only
>>> difference is that on the problematic one I have a lot more mailing
>>> lists/archives and that I imported them from mailman2. Could something
>>> have gone wrong during the import? I used the regular hyperkitty_import
>>> command.
>> Yes, this is because `whoosh`, the library set by default to run
>> fulltext
>> indexing is a pure python implementation and quite slow in busy lists.
>>
>> We do support more backends though, see [1] for a list of all the
>> supported
>> search backends. Something like Xapian(C++) or Elasticsearch/Solr(Java)
>> should be much better in terms of performance.
>>
>> [1]:
>> https://django-haystack.readthedocs.io/en/master/backend_support.html
>>
>>> uwsgi-error.log:
>>>
>>> *** Starting uWSGI 2.0.18 (64bit) on [Sat Apr 27 22:50:17 2019]
>>> ***
>>> compiled with version: 6.4.0 on 27 April 2019 22:48:42
>>> os: Linux-4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19)
>>> nodename: hyperkitty.docker
>>> machine: x86_64
>>> clock source: unix
>>> detected number of CPU cores: 4
>>> current working directory: /home/hyperkitty
>>> detected binary path: /usr/local/bin/uwsgi
>>> !!! no internal routing support, rebuild with pcre support !!!
>>> setgid() to 82
>>> setuid() to 82
>>> chdir() to /home/hyperkitty
>>> your memory page size is 4096 bytes
>>> detected max file descriptor number: 1048576
>>> lock engine: pthread robust mutexes
>>> thunder lock: disabled (you can enable it with --thunder-lock)
>>> uwsgi socket 0 bound to TCP address 0.0.0.0:8081 fd 8
>>> uwsgi socket 1 bound to TCP address 0.0.0.0:8080 fd 9
>>> Python version: 3.6.8 (default, Jan 30 2019, 23:54:38) [GCC 6.4.0]
>>> Python main interpreter initialized at 0x55dfaa41c980
>>> python threads support enabled
>>> your server socket listen backlog is limited to 100 connections
>>> your mercy for graceful operations on workers is 60 seconds
>>> [uwsgi-cron] command "./manage.py runjobs minutely" registered as
>>> cron task
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly"
>>> registered
>>> as cron task
>>> [uwsgi-cron] command "./manage.py runjobs hourly" registered as
>>> cron
>>> task
>>> [uwsgi-cron] command "./manage.py runjobs daily" registered as
>>> cron task
>>> [uwsgi-cron] command "./manage.py runjobs monthly" registered as
>>> cron task
>>> [uwsgi-cron] command "./manage.py runjobs weekly" registered as
>>> cron
>>> task
>>> [uwsgi-cron] command "./manage.py runjobs yearly" registered as
>>> cron
>>> task
>>> mapped 208576 bytes (203 KB) for 4 cores
>>> *** Operational MODE: threaded ***
>>> WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter
>>> 0x55dfaa41c980 pid: 1 (default app)
>>> *** uWSGI is running in multiple interpreter mode ***
>>> spawned uWSGI master process (pid: 1)
>>> spawned uWSGI worker 1 (pid: 40, cores: 4)
>>> Sat Apr 27 22:50:18 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> minutely" (pid 45)
>>> [uwsgi-daemons] spawning "./manage.py qcluster" (uid: 82 gid: 82)
>>> 22:50:21 [Q] INFO Q Cluster-47 starting.
>>> 22:50:21 [Q] INFO Process-1:1 ready for work at 59
>>> 22:50:21 [Q] INFO Process-1:2 ready for work at 60
>>> 22:50:21 [Q] INFO Process-1:3 ready for work at 61
>>> 22:50:21 [Q] INFO Process-1:4 ready for work at 62
>>> 22:50:21 [Q] INFO Process-1:5 monitoring at 63
>>> 22:50:21 [Q] INFO Process-1 guarding cluster at 58
>>> 22:50:21 [Q] INFO Process-1:6 pushing tasks at 64
>>> 22:50:21 [Q] INFO Q Cluster-47 running.
>>> 22:59:31 [Q] INFO Enqueued 3403
>>> 22:59:31 [Q] INFO Process-1:1 processing [update_from_mailman]
>>> 22:59:33 [Q] INFO Processed [update_from_mailman]
>>> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> quarter_hourly" (pid 73)
>>> Sat Apr 27 23:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> hourly" (pid 74)
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>>> with pid 73 exited after 64 second(s)
>>> 23:01:28 [Q] INFO Enqueued 3404
>>> 23:01:29 [Q] INFO Process-1:2 processing
>>> [rebuild_mailinglist_cache_recent]
>>> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
>>> 74 exited after 91 second(s)
>>> Sat Apr 27 23:01:36 2019 - uwsgi_response_write_body_do(): Broken
>>> pipe [core/writer.c line 341] during GET / (212.203.58.154)
>>> OSError: write error
>>> 23:01:36 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
>>> Sat Apr 27 23:15:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> quarter_hourly" (pid 88)
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>>> with pid 88 exited after 4 second(s)
>>> 23:28:24 [Q] INFO Enqueued 3405
>>> 23:28:24 [Q] INFO Process-1:3 processing [update_from_mailman]
>>> 23:28:25 [Q] INFO Processed [update_from_mailman]
>>> Sat Apr 27 23:30:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> quarter_hourly" (pid 96)
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>>> with pid 96 exited after 4 second(s)
>>> 23:44:40 [Q] INFO Enqueued 3406
>>> 23:44:40 [Q] INFO Process-1:4 processing [update_from_mailman]
>>> 23:44:41 [Q] INFO Processed [update_from_mailman]
>>> Sat Apr 27 23:45:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> quarter_hourly" (pid 104)
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>>> with pid 104 exited after 4 second(s)
>>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> quarter_hourly" (pid 113)
>>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> hourly" (pid 114)
>>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> daily" (pid 115)
>>> Sun Apr 28 00:00:00 2019 - [uwsgi-cron] running "./manage.py
>>> runjobs
>>> weekly" (pid 116)
>>> [uwsgi-cron] command "./manage.py runjobs quarter_hourly" running
>>> with pid 113 exited after 55 second(s)
>>> [uwsgi-cron] command "./manage.py runjobs weekly" running with pid
>>> 116 exited after 55 second(s)
>>> 00:01:36 [Q] INFO Enqueued 3407
>>> 00:01:36 [Q] INFO Process-1:1 processing
>>> [rebuild_mailinglist_cache_recent]
>>> [uwsgi-cron] command "./manage.py runjobs hourly" running with pid
>>> 114 exited after 99 second(s)
>>> 00:01:50 [Q] INFO Processed [rebuild_mailinglist_cache_recent]
>>> 00:04:52 [Q] INFO Enqueued 3408
>>> 00:04:52 [Q] INFO Process-1:2 processing [update_from_mailman]
>>> 00:04:54 [Q] INFO Processed [update_from_mailman]
>>>
>>> Dockerfile:
>>>
>>> FROM python:3.6-alpine3.7 # Add startup script to container COPY
>>> assets/docker-entrypoint.sh /usr/local/bin/ # Install packages and
>>> dependencies for hyperkitty and add user for executing apps. #
>>> It's
>>> important that the user has the UID/GID 82 so nginx can access the
>>> files. RUN set -ex \&& apk add --no-cache --virtual .build-deps
>>> gcc
>>> libc-dev linux-headers git \postgresql-dev \&& apk add --no-cache
>>> --virtual .mailman-rundeps bash sassc mailcap \postgresql-client
>>> curl \&& pip install -U django==2.2 \&& pip install
>>> git+https://gitlab.com/eestec/mailmanclient
>>> \git+https://gitlab.com/mailman/hyperkitty@c9fa4d4bfc295438d3e01cd93090064d004cf44d
>>> \git+https://gitlab.com/eestec/django-mailman3 \whoosh \uwsgi
>>> \psycopg2 \dj-database-url \typing \&& apk del .build-deps \&&
>>> addgroup -S -g 82 hyperkitty \&& adduser -S -u 82 -G hyperkitty
>>> hyperkitty \&& chmod u+x /usr/local/bin/docker-entrypoint.sh# Add
>>> needed files for uwsgi server + settings for django COPY
>>> assets/__init__.py /home/hyperkittyCOPY assets/manage.py
>>> /home/hyperkittyCOPY assets/urls.py /home/hyperkittyCOPY
>>> assets/wsgi.py /home/hyperkittyCOPY assets/uwsgi.ini
>>> /home/hyperkittyCOPY assets/settings.py /home/hyperkitty# Change
>>> ownership for uwsgi+django files and set execution rights for
>>> management script RUN chown -R hyperkitty /home/hyperkitty &&
>>> chmod
>>> u+x /home/hyperkitty/manage.py# Make sure we are in the correct
>>> working dir WORKDIR /home/hyperkittyEXPOSE 8080 8081# Use stop
>>> signal for uwsgi server STOPSIGNAL SIGINTENTRYPOINT
>>> ["docker-entrypoint.sh"]CMD ["uwsgi", "--ini",
>>> "/home/hyperkitty/uwsgi.ini"]
>>>
>>> On 4/27/19 7:58 PM, Abhilash Raj wrote:
>>>> On Sat, Apr 27, 2019, at 9:40 AM, Alain Kohli wrote:
>>>>> I have run "python manage.py rebuild_index" before, doesn't that do
>>>>> clear_index as well? Apart from that, I run hyperkitty in a docker
>>>>> container and didn't know fulltext_index should be persistent, so
>>>>> that
>>>>> got deleted after every version update for sure.
>>>> Which images are you using and how are you deploying them?
>>>>
>>>> You should persist fulltext_index, yes, and possibly logs if you need
>>>> them for debugging later.
>>>>
>>>> Can you paste the entire error traceback?
>>>>
>>>>> On 4/26/19 10:18 PM, Mark Sapiro wrote:
>>>>>> On 4/26/19 11:14 AM, Alain Kohli wrote:
>>>>>>> I see loads of "A string literal cannot contain NUL (0x00)
>>>>>>> characters."
>>>>>>> messages, but I haven't found missing messages in the archives
>>>>>>> yet. Not
>>>>>>> sure how that could be related, though. Apart from that I don't see
>>>>>>> anything unusual. The other jobs (quarter_hourly, hourly, etc.)
>>>>>>> seem to
>>>>>>> run and finish normally.
>>>>>> Did you upgrade from a Python 2.7 version of HyperKitty to a
>>>>>> Python 3
>>>>>> version? The Haystack/Whoosh search engine databases are not
>>>>>> compatible
>>>>>> between the two and "A string literal cannot contain NUL (0x00)
>>>>>> characters." is the symptom.
>>>>>>
>>>>>> You need to run 'python manage.py clear_index' or just remove all
>>>>>> the
>>>>>> files from the directory defined as 'PATH' under
>>>>>> HAYSTACK_CONNECTIONS in
>>>>>> your settings file (normally 'fulltext_index' in the same
>>>>>> directory that
>>>>>> contains your settings.py.
>>>>>>
>>>>> _______________________________________________
>>>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>>>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>>>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>>>
>>> _______________________________________________
>>> Mailman-users mailing list -- mailman-users(a)mailman3.org
>>> To unsubscribe send an email to mailman-users-leave(a)mailman3.org
>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
>>>
>
6 years, 8 months
[MM3-users] Re: Mailman sends Welcome emails, but does not send [List] postings emails
by Nelson Strother
Here are the (four identical, but for timestamps and process numbers, at
a glance) tracebacks, and some related info:
--- from /var/log/syslog
Jun 8 03:35:47 localhost mailman[13107]: Traceback (most recent call last):
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/bin/runner", line 8, in <module>
Jun 8 03:35:48 localhost mailman[13107]: sys.exit(main())
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1130, in __call__
Jun 8 03:35:48 localhost mailman[13107]: return self.main(*args,
**kwargs)
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1055, in main
Jun 8 03:35:48 localhost mailman[13107]: rv = self.invoke(ctx)
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1404, in invoke
Jun 8 03:35:48 localhost mailman[13107]: return
ctx.invoke(self.callback, **ctx.params)
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 760, in invoke
Jun 8 03:35:48 localhost mailman[13107]: return __callback(*args,
**kwargs)
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/decorators.py",
line 26, in new_func
Jun 8 03:35:48 localhost mailman[13107]: return
f(get_current_context(), *args, **kwargs)
Jun 8 03:35:48 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/bin/runner.py",
line 160, in main
Jun 8 03:35:49 localhost mailman[13107]: initialize(config_file, verbose)
Jun 8 03:35:49 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 231, in initialize
Jun 8 03:35:49 localhost mailman[13107]:
initialize_2(propagate_logs=propagate_logs)
Jun 8 03:35:49 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 189, in initialize_2
Jun 8 03:35:49 localhost mailman[13107]: config.db =
getUtility(IDatabaseFactory, utility_name).create()
Jun 8 03:35:49 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/database/factory.py",
line 60, in create
Jun 8 03:35:49 localhost mailman[13107]: return database
Jun 8 03:35:49 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 470, in __exit__
Jun 8 03:35:49 localhost mailman[13107]: self.unlock()
Jun 8 03:35:49 localhost mailman[13107]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 420, in unlock
Jun 8 03:35:49 localhost mailman[13107]: raise
NotLockedError('Already unlocked')
Jun 8 03:35:49 localhost mailman[13107]:
flufl.lock._lockfile.NotLockedError: Already unlocked
Jun 8 03:35:49 localhost dhclient[633]: RCV: Advertise message on
ens192 from fe80::250:56ff:fe95:b457.
Jun 8 03:36:46 localhost mailman[13100]: Traceback (most recent call last):
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/bin/runner", line 8, in <module>
Jun 8 03:36:46 localhost mailman[13100]: sys.exit(main())
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1130, in __call__
Jun 8 03:36:46 localhost mailman[13100]: return self.main(*args,
**kwargs)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1055, in main
Jun 8 03:36:46 localhost mailman[13100]: rv = self.invoke(ctx)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1404, in invoke
Jun 8 03:36:46 localhost mailman[13100]: return
ctx.invoke(self.callback, **ctx.params)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 760, in invoke
Jun 8 03:36:46 localhost mailman[13100]: return __callback(*args,
**kwargs)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/decorators.py",
line 26, in new_func
Jun 8 03:36:46 localhost mailman[13100]: return
f(get_current_context(), *args, **kwargs)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/bin/runner.py",
line 160, in main
Jun 8 03:36:46 localhost mailman[13100]: initialize(config_file, verbose)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 231, in initialize
Jun 8 03:36:46 localhost mailman[13100]:
initialize_2(propagate_logs=propagate_logs)
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 189, in initialize_2
Jun 8 03:36:46 localhost mailman[13100]: config.db =
getUtility(IDatabaseFactory, utility_name).create()
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/database/factory.py",
line 60, in create
Jun 8 03:36:46 localhost mailman[13100]: return database
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 470, in __exit__
Jun 8 03:36:46 localhost mailman[13100]: self.unlock()
Jun 8 03:36:46 localhost mailman[13100]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 420, in unlock
Jun 8 03:36:46 localhost mailman[13100]: raise
NotLockedError('Already unlocked')
Jun 8 03:36:46 localhost mailman[13100]:
flufl.lock._lockfile.NotLockedError: Already unlocked
Jun 8 03:36:56 localhost mailman[13109]: Traceback (most recent call last):
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/bin/runner", line 8, in <module>
Jun 8 03:36:56 localhost mailman[13109]: sys.exit(main())
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1130, in __call__
Jun 8 03:36:56 localhost mailman[13109]: return self.main(*args,
**kwargs)
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1055, in main
Jun 8 03:36:56 localhost mailman[13109]: rv = self.invoke(ctx)
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1404, in invoke
Jun 8 03:36:56 localhost mailman[13109]: return
ctx.invoke(self.callback, **ctx.params)
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 760, in invoke
Jun 8 03:36:56 localhost mailman[13109]: return __callback(*args,
**kwargs)
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/decorators.py",
line 26, in new_func
Jun 8 03:36:56 localhost mailman[13109]: return
f(get_current_context(), *args, **kwargs)
Jun 8 03:36:56 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/bin/runner.py",
line 160, in main
Jun 8 03:36:56 localhost postfix/anvil[13147]: statistics: max
connection rate 1/60s for (smtp:163.123.143.10) at Jun 8 03:33:27
Jun 8 03:37:00 localhost postfix/anvil[13147]: statistics: max
connection count 1 for (smtp:163.123.143.10) at Jun 8 03:33:27
Jun 8 03:37:00 localhost mailman[13109]: initialize(config_file, verbose)
Jun 8 03:37:01 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 231, in initialize
Jun 8 03:37:01 localhost mailman[13109]:
initialize_2(propagate_logs=propagate_logs)
Jun 8 03:37:01 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 189, in initialize_2
Jun 8 03:37:01 localhost mailman[13109]: config.db =
getUtility(IDatabaseFactory, utility_name).create()
Jun 8 03:37:01 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/database/factory.py",
line 60, in create
Jun 8 03:37:01 localhost mailman[13109]: return database
Jun 8 03:37:01 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 470, in __exit__
Jun 8 03:37:01 localhost mailman[13109]: self.unlock()
Jun 8 03:37:01 localhost mailman[13109]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 420, in unlock
Jun 8 03:37:01 localhost mailman[13109]: raise
NotLockedError('Already unlocked')
Jun 8 03:37:01 localhost mailman[13109]:
flufl.lock._lockfile.NotLockedError: Already unlocked
Jun 8 03:37:01 localhost postfix/anvil[13147]: statistics: max cache
size 1 at Jun 8 03:33:27
Jun 8 03:37:01 localhost mailman[13110]: Traceback (most recent call last):
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/bin/runner", line 8, in <module>
Jun 8 03:37:01 localhost mailman[13110]: sys.exit(main())
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1130, in __call__
Jun 8 03:37:01 localhost mailman[13110]: return self.main(*args,
**kwargs)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1055, in main
Jun 8 03:37:01 localhost mailman[13110]: rv = self.invoke(ctx)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 1404, in invoke
Jun 8 03:37:01 localhost mailman[13110]: return
ctx.invoke(self.callback, **ctx.params)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/core.py",
line 760, in invoke
Jun 8 03:37:01 localhost mailman[13110]: return __callback(*args,
**kwargs)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/click/decorators.py",
line 26, in new_func
Jun 8 03:37:01 localhost mailman[13110]: return
f(get_current_context(), *args, **kwargs)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/bin/runner.py",
line 160, in main
Jun 8 03:37:01 localhost mailman[13110]: initialize(config_file, verbose)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 231, in initialize
Jun 8 03:37:01 localhost mailman[13110]:
initialize_2(propagate_logs=propagate_logs)
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 189, in initialize_2
Jun 8 03:37:01 localhost mailman[13110]: config.db =
getUtility(IDatabaseFactory, utility_name).create()
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/database/factory.py",
line 60, in create
Jun 8 03:37:01 localhost mailman[13110]: return database
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 470, in __exit__
Jun 8 03:37:01 localhost mailman[13110]: self.unlock()
Jun 8 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 420, in unlock
Jun 8 03:37:01 localhost mailman[13110]: raise
NotLockedError('Already unlocked')
Jun 8 03:37:01 localhost mailman[13110]:
flufl.lock._lockfile.NotLockedError: Already unlocked
--- note that processes 13100, 13107, 13109, and 13110 are the ones
missing from the sequential process numbers shown by systemctl status
mailman below, were presumably momentarily the missing command, digests,
retry, and virgin runners ...
-- all of the recent lines from /var/tmp/mailman/logs/mailman.log :
Jun 08 03:24:17 2023 (4268) Master stopped
Jun 08 03:30:18 2023 (13093) Master started
Jun 08 03:43:31 2023 (13108) task runner started.
Jun 08 03:43:52 2023 (13108) Task runner evicted 0 expired pendings
Jun 08 03:43:52 2023 (13108) Task runner deleted 0 orphaned workflows
Jun 08 03:43:53 2023 (13108) Task runner deleted 0 orphaned requests
Jun 08 03:43:54 2023 (13108) Task runner deleted 0 orphaned messages
Jun 08 03:43:54 2023 (13108) Task runner evicted expired cache entries
Jun 08 03:44:17 2023 (13101) in runner started.
Jun 08 03:44:23 2023 (13105) pipeline runner started.
Jun 08 03:44:54 2023 (13103) nntp runner started.
Jun 08 03:45:59 2023 (13098) archive runner started.
Jun 08 03:46:06 2023 (13104) out runner started.
Jun 08 03:46:23 2023 (13099) bounces runner started.
Jun 08 03:46:43 2023 (13106) rest runner started.
[2023-06-08 03:46:43 +0000] [13106] [INFO] Starting gunicorn 20.1.0
[2023-06-08 03:46:43 +0000] [13106] [INFO] Listening at:
http://127.0.0.1:8001 (13106)
[2023-06-08 03:46:43 +0000] [13106] [INFO] Using worker: sync
[2023-06-08 03:46:44 +0000] [13345] [INFO] Booting worker with pid: 13345
[2023-06-08 03:46:44 +0000] [13346] [INFO] Booting worker with pid: 13346
Jun 08 03:46:46 2023 (13102) lmtp runner started.
Jun 08 04:44:04 2023 (13108) Task runner evicted 0 expired pendings
Jun 08 04:44:04 2023 (13108) Task runner deleted 0 orphaned workflows
Jun 08 04:44:05 2023 (13108) Task runner deleted 0 orphaned requests
Jun 08 04:44:05 2023 (13108) Task runner deleted 0 orphaned messages
Jun 08 04:44:05 2023 (13108) Task runner evicted expired cache entries
{with these last five lines being repeated hourly since ...}
--
root@localhost:~# systemctl status mailman
● mailman.service - GNU Mailing List Manager
Loaded: loaded (/etc/systemd/system/mailman.service; enabled;
vendor preset: enabled)
Active: active (running) since Thu 2023-06-08 03:30:18 UTC; 13h ago
Process: 13092 ExecStart=/var/tmp/mailman/.local/bin/mailman
--config /var/tmp/mailman/var/etc/mailman.cfg start (code=exited,
status=0/SUCCESS)
Main PID: 13093 (python3)
Tasks: 17 (limit: 465)
Memory: 73.5M
CPU: 15min 23.511s
CGroup: /system.slice/mailman.service
├─13093 /usr/bin/python3
/var/tmp/mailman/.local/bin/master -C /var/tmp/mailman/var/etc/mailman.cfg
├─13098 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=archive:0:1
├─13099 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=bounces:0:1
├─13101 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=in:0:1
├─13102 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=lmtp:0:1
├─13103 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=nntp:0:1
├─13104 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=out:0:1
├─13105 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=pipeline:0:1
├─13106 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=rest:0:1
├─13108 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=task:0:1
├─13345 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=rest:0:1
└─13346 /usr/bin/python3
/var/tmp/mailman/.local/bin/runner -C
/var/tmp/mailman/var/etc/mailman.cfg --runner=rest:0:1
Jun 08 03:37:01 localhost mailman[13110]:
initialize_2(propagate_logs=propagate_logs)
Jun 08 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/core/initialize.py",
line 189, in initialize_2
Jun 08 03:37:01 localhost mailman[13110]: config.db =
getUtility(IDatabaseFactory, utility_name).create()
Jun 08 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/mailman/database/factory.py",
line 60, in create
Jun 08 03:37:01 localhost mailman[13110]: return database
Jun 08 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 470, in __exit__
Jun 08 03:37:01 localhost mailman[13110]: self.unlock()
Jun 08 03:37:01 localhost mailman[13110]: File
"/var/tmp/mailman/.local/lib/python3.9/site-packages/flufl/lock/_lockfile.py",
line 420, in unlock
Jun 08 03:37:01 localhost mailman[13110]: raise
NotLockedError('Already unlocked')
Jun 08 03:37:01 localhost mailman[13110]:
flufl.lock._lockfile.NotLockedError: Already unlocked
root@localhost:~#
On 6/8/23 13:02, Mark Sapiro wrote:
> On 6/7/23 21:30, Nelson Strother wrote:
>>
>> Interestingly if I use `systemctl start mailman` thus far the results
>> are:
>> - the wall clock duration is shorter than when `mailman start` is
>> issued from the command line, and
>> -- either that all of the runners remain present once they are started,
>> -- or I can see in syslog a traceback from each missing runner
>> process starting from .../mailman/.local/bin/runner and ending with
>> "flufl.lock._lockfile.NotLockedError: Already unlocked".
>>
>> I do not yet understand how to make use of these clues, but at least
>> one can see an epitaph from each deceased process.
>
>
> The NotLockedError is most likely because a lock has been set with a
> lifetime and its lifetime has passed and some other process has broken
> the lock before the original process tries to unlock it. This probably
> has something to do with the long times to do start/restart.
>
> However, the only lock that should be involved is the master lock set
> by the master watcher, so I don't really understand what might be
> happening.
>
> What is the full traceback from these errors?
>
2 years, 8 months