Christian Schoepplein via Mailman-users writes:
I'd like to have a seperate log for list subscriptions and unsubscriptions. For that reason I added the following section to the mailman-extra.cfg file:
[logging.subscribe] path: subscribe.log
That created a file called subscribe.log but not everything regarding subscription / unsubscriptions is added to the file. When subscribing and unsubscribing a user via mail only the following line is shown:
Aug 27 10:58:31 2021 (28) tmod@mm3.example.com: held subscription request from chris@example.com
It's weird that that shows up in subscribe.log; I would expect it in vette.log. Maybe I'm misunderstanding the exact semantics of "vette", though.
Nothing regarding the finished subscription and absolutely nothing regarding the unsubscription performed later.
Please be specific about what information you want in the log about these events. I would guess that you would find more information except for the bug below. More about that later when I or one of the other devs has time to look at the code carefully. I suspect that configuring a separate subscribe.log is unusual and that triggered the bug, FWIW.
Also in mailman.log I can find the following lines:
Aug 27 10:58:05 2021 (28) deque: do_confirm_verify Traceback (most recent call last): File "/usr/lib/python3.8/site-packages/mailman/app/workflow.py", line 69, in __next__ return step() File "/usr/lib/python3.8/site-packages/mailman/app/subscriptions.py", line 356, in _step_send_confirmation raise StopIteration StopIteration [...] Is this because a higher logging level or is this an error?
This is a bug, most likely in Mailman. StopIteration should never be seen by anything but an iteration syntax, which should catch it and stop.[1]
I can find nothing really helpfull regarding subscriptions and unsubscriptions in any logfile.
That's mostly because we don't know what other people consider "helpful". You can specify the events and data you want to see, or you can tell us what you want to use them for and we'll help with the specification.
Footnotes: [1] OK, *almost* never. I actually suggested def is_empty(thing): try: next(iter(thing)) return False except StopIteration return True as a test for emptiness of certain containers recently. :-)