Mailman 3, container images 0.1.1
HyperKitty 1.1.1 is showing incorrect numbers for the number of participants and the number of discussions.
(All messages referred to below were submitted in August.)
In one list, I have two threads. In one thread, I have three messages, each from a different email address, all submitted via email (as opposed to replying from within HyperKitty). The month page (clicking on “August”) of that list however, shows that thread as having one participant and no messages. Opening the list shows the same stats: “1 participants”, “0 comments”; all three messages are displayed.
The other thread in the same list also shows one participant and no messages; it has two messages in it, one submitted via email, the other submitted via HyperKitty by a different subscriber. Opening the list shows both messages.
The front page of that list shows zero participants and two discussions.
A second list also has two threads with three email-submitted messages from different addresses. The monthly stats show one thread as having one participant and one message, the other as having one participant and zero messages. The front page shows one participant and one discussion.
Cameron Smith
On Wed, 16 Aug 2017 09:18:59 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Mailman 3, container images 0.1.1
HyperKitty 1.1.1 is showing incorrect numbers for the number of participants and the number of discussions.
(All messages referred to below were submitted in August.)
In one list, I have two threads. In one thread, I have three messages, each from a different email address, all submitted via email (as opposed to replying from within HyperKitty). The month page (clicking on “August”) of that list however, shows that thread as having one participant and no messages. Opening the list shows the same stats: “1 participants”, “0 comments”; all three messages are displayed.
The other thread in the same list also shows one participant and no messages; it has two messages in it, one submitted via email, the other submitted via HyperKitty by a different subscriber. Opening the list shows both messages.
The front page of that list shows zero participants and two discussions.
A second list also has two threads with three email-submitted messages from different addresses. The monthly stats show one thread as having one participant and one message, the other as having one participant and zero messages. The front page shows one participant and one discussion.
Statistics are generated by routine tasks which are usually meant to be run as cron jobs. In the docker container, uwsgi is responsible to run them.
If you are using the standard directory structure mentioned in the documentation for Mailman 3, you will find the logs for cron at /opt/mailman/web/logs/uwsg-cron.log
It should tell if you if the log daemons are running as they are supposed to.
I am not sure which job exactly is supposed to generate stats, but if you see
the logs running with manage.py runjobs minutely every minute, then probably
the problem lies somewhere else.
Cameron Smith
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj
Hmm… something is definitely not right.
/opt/mailman/web/logs/uwsgi-cron.log has not been updated since Aug 11, which is when I installed the container images 0.1.1. However, /opt/mailman/web/logs/uwsg-error.log is being updated every minute with entries similar to this:
Sun Aug 20 13:40:00 2017 - [uwsgi-cron] running "./manage.py runjobs minutely" (pid 123) [uwsgi-cron] command “./manage.py runjobs minutely" running with pid 123 exited after 2 second(s)
In addition (and possibly related) to this, HyperKitty is “losing” messages; threads with multiple messages will suddenly lose all but the top message. A new subscriber will be told that there are unread messages, but none but the top message will appear. Actually, this isn’t entirely true: all of the messages in *one* of the threads have suddenly reappeared for no apparent reason…
On 2017.08.19, at 00:04 , Abhilash Raj <maxking@asynchronous.in> wrote:
On Wed, 16 Aug 2017 09:18:59 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Mailman 3, container images 0.1.1
HyperKitty 1.1.1 is showing incorrect numbers for the number of participants and the number of discussions.
(All messages referred to below were submitted in August.)
In one list, I have two threads. In one thread, I have three messages, each from a different email address, all submitted via email (as opposed to replying from within HyperKitty). The month page (clicking on “August”) of that list however, shows that thread as having one participant and no messages. Opening the list shows the same stats: “1 participants”, “0 comments”; all three messages are displayed.
The other thread in the same list also shows one participant and no messages; it has two messages in it, one submitted via email, the other submitted via HyperKitty by a different subscriber. Opening the list shows both messages.
The front page of that list shows zero participants and two discussions.
A second list also has two threads with three email-submitted messages from different addresses. The monthly stats show one thread as having one participant and one message, the other as having one participant and zero messages. The front page shows one participant and one discussion.
Statistics are generated by routine tasks which are usually meant to be run as cron jobs. In the docker container, uwsgi is responsible to run them.
If you are using the standard directory structure mentioned in the documentation for Mailman 3, you will find the logs for cron at /opt/mailman/web/logs/uwsg-cron.log
It should tell if you if the log daemons are running as they are supposed to.
I am not sure which job exactly is supposed to generate stats, but if you see the logs running with
manage.py runjobs minutelyevery minute, then probably the problem lies somewhere else.Cameron Smith
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- thanks, Abhilash Raj
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Cameron Smith
On Sun, 20 Aug 2017 08:38:53 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Hmm… something is definitely not right.
/opt/mailman/web/logs/uwsgi-cron.log has not been updated since Aug 11, which is when I installed the container images 0.1.1. However, /opt/mailman/web/logs/uwsg-error.log is being updated every minute with entries similar to this:
Sun Aug 20 13:40:00 2017 - [uwsgi-cron] running "./manage.py runjobs minutely" (pid 123) [uwsgi-cron] command “./manage.py runjobs minutely" running with pid 123 exited after 2 second(s)
This seems like a bug in the uwsgi configuration, it should actually go to uwsgi-cron.log. I have opened a new bug1 to track this problem.
In addition (and possibly related) to this, HyperKitty is “losing” messages; threads with multiple messages will suddenly lose all but the top message. A new subscriber will be told that there are unread messages, but none but the top message will appear. Actually, this isn’t entirely true: all of the messages in *one* of the threads have suddenly reappeared for no apparent reason…
This looks like a bug in Hyperkitty, can you open an issue on Gitlab2 for the same?
On 2017.08.19, at 00:04 , Abhilash Raj <maxking@asynchronous.in> wrote:
On Wed, 16 Aug 2017 09:18:59 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
[...]
Statistics are generated by routine tasks which are usually meant to be run as cron jobs. In the docker container, uwsgi is responsible to run them.
If you are using the standard directory structure mentioned in the documentation for Mailman 3, you will find the logs for cron at /opt/mailman/web/logs/uwsg-cron.log
It should tell if you if the log daemons are running as they are supposed to.
I am not sure which job exactly is supposed to generate stats, but if you see the logs running with
manage.py runjobs minutelyevery minute, then probably the problem lies somewhere else.[...]
-- thanks, Abhilash Raj
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Cameron Smith
-- thanks, Abhilash Raj
Abhilash,
I think the location of the message, in the error log, is correct: in the uwsci-cron.log, the entries show that the “minutely” jobs run for 32-33 seconds, whereas the entries in the error log show the jobs as running for only 2 seconds, suggesting an error. (As an aside, what is “minutely” doing that takes 32-33 seconds?)
How best can I diagnose the problem? If need be, I can simply tear down the whole system, including deleting /opt/mailman on the host, start again and see if the problem persists. I think it would, however, be more helpful if we could figure out what has gone wrong.
On 2017.08.20, at 14:34 , Abhilash Raj <maxking@asynchronous.in> wrote:
On Sun, 20 Aug 2017 08:38:53 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Hmm… something is definitely not right.
/opt/mailman/web/logs/uwsgi-cron.log has not been updated since Aug 11, which is when I installed the container images 0.1.1. However, /opt/mailman/web/logs/uwsg-error.log is being updated every minute with entries similar to this:
Sun Aug 20 13:40:00 2017 - [uwsgi-cron] running "./manage.py runjobs minutely" (pid 123) [uwsgi-cron] command “./manage.py runjobs minutely" running with pid 123 exited after 2 second(s)
This seems like a bug in the uwsgi configuration, it should actually go to uwsgi-cron.log. I have opened a new bug1 to track this problem.
Cameron Smith
On Thu, Aug 24, 2017, at 09:42 AM, Cameron Smith wrote:
Abhilash,
I think the location of the message, in the error log, is correct: in the uwsci-cron.log, the entries show that the “minutely” jobs run for 32-33 seconds, whereas the entries in the error log show the jobs as running for only 2 seconds, suggesting an error. (As an aside, what is “minutely” doing that takes 32-33 seconds?)
Yeah, if there are no entries going to uwsgi-cron at all, it looks like there is some configuration problem in log routing. T this1 is the uwsgi configuration that is supposed to route the cron related logs to uwsgi-cron.log.
Also, I am not exactly sure of what jobs run "minutely", 2 is the place where all of them are defined if you want to dive in yourself. Jobs (class) have a method "when" which defines when they run like "hourly", "daily" etc.
How best can I diagnose the problem? If need be, I can simply tear down the whole system, including deleting /opt/mailman on the host, start again and see if the problem persists. I think it would, however, be more helpful if we could figure out what has gone wrong.
I am not sure what exactly is the problem, opening an issue with Hyperkitty3 might be worth it to see if the devs have ideas about it. If this is a problem with Hyperkitty, I'd assume it would also be visible on the archives on this list, which runs on Mailman 3 (and not using containers AFAIK).
On 2017.08.20, at 14:34 , Abhilash Raj <maxking@asynchronous.in> wrote:
On Sun, 20 Aug 2017 08:38:53 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Hmm… something is definitely not right.
/opt/mailman/web/logs/uwsgi-cron.log has not been updated since Aug 11, which is when I installed the container images 0.1.1. However, /opt/mailman/web/logs/uwsg-error.log is being updated every minute with entries similar to this:
Sun Aug 20 13:40:00 2017 - [uwsgi-cron] running "./manage.py runjobs minutely" (pid 123) [uwsgi-cron] command “./manage.py runjobs minutely" running with pid 123 exited after 2 second(s)
This seems like a bug in the uwsgi configuration, it should actually go to uwsgi-cron.log. I have opened a new bug1 to track this problem.
Cameron Smith
-- Abhilash Raj maxking@asynchronous.in
On Thu, Aug 24, 2017, at 10:09 AM, Abhilash Raj wrote:
On Thu, Aug 24, 2017, at 09:42 AM, Cameron Smith wrote:
Abhilash,
I think the location of the message, in the error log, is correct: in the uwsci-cron.log, the entries show that the “minutely” jobs run for 32-33 seconds, whereas the entries in the error log show the jobs as running for only 2 seconds, suggesting an error. (As an aside, what is “minutely” doing that takes 32-33 seconds?)
Just as an FYI, my test server running the container images also has minutely jobs taking 2 seconds and older entries in uwsgi-cron.log being 32-33 seconds.
Note that this change in time could be something that was changed in Hyperkitty 1.1.1, I haven't yet read the changelog to infer that part yet. Since this problem started happening once you upgraded to 0.1.1 images, which use HK 1.1.1.
Yeah, if there are no entries going to uwsgi-cron at all, it looks like there is some configuration problem in log routing. T this1 is the uwsgi configuration that is supposed to route the cron related logs to uwsgi-cron.log.
Also, I am not exactly sure of what jobs run "minutely", 2 is the place where all of them are defined if you want to dive in yourself. Jobs (class) have a method "when" which defines when they run like "hourly", "daily" etc.
How best can I diagnose the problem? If need be, I can simply tear down the whole system, including deleting /opt/mailman on the host, start again and see if the problem persists. I think it would, however, be more helpful if we could figure out what has gone wrong.
I am not sure what exactly is the problem, opening an issue with Hyperkitty3 might be worth it to see if the devs have ideas about it. If this is a problem with Hyperkitty, I'd assume it would also be visible on the archives on this list, which runs on Mailman 3 (and not using containers AFAIK).
On 2017.08.20, at 14:34 , Abhilash Raj <maxking@asynchronous.in> wrote:
On Sun, 20 Aug 2017 08:38:53 -0700 Cameron Smith <ccsmith@cetsi.com> wrote:
Hmm… something is definitely not right.
/opt/mailman/web/logs/uwsgi-cron.log has not been updated since Aug 11, which is when I installed the container images 0.1.1. However, /opt/mailman/web/logs/uwsg-error.log is being updated every minute with entries similar to this:
Sun Aug 20 13:40:00 2017 - [uwsgi-cron] running "./manage.py runjobs minutely" (pid 123) [uwsgi-cron] command “./manage.py runjobs minutely" running with pid 123 exited after 2 second(s)
This seems like a bug in the uwsgi configuration, it should actually go to uwsgi-cron.log. I have opened a new bug1 to track this problem.
Cameron Smith
-- Abhilash Raj maxking@asynchronous.in
Mailman-users mailing list mailman-users@mailman3.org https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
-- Abhilash Raj maxking@asynchronous.in
participants (2)
-
Abhilash Raj -
Cameron Smith