Danil Smirnov writes:
Thank you Steve for your comments, but I am still interested in knowing how Mailman developers would debug issues with Hyperkitty periodic tasks.
I'd start by checking if the relevant process (probably qcluster) is actually running -- in my experience the most common reason for ZERO logs is the process isn't running.
I'll tell you what I'd do after that *because* a developer should track this stuff down, but if everything failed, purely as a matter of debugging I'd just change the default in the update_index function to verbosity=1, then change it back (or to 2, etc) once you have whatever information that gives you. That's what I recommend you do once you have confirmed the process is running.
Then while waiting on the user channels I'd grep for 'search_indexes' in import statements to see where search_index.update_index is called to see how that 'verbosity' parameter gets set. It may be ignored (defaulted to 0) or hardcoded, but there may also be a option that can be set in the LOGGING parameter of settings.py.
If that doesn't work, I'd trace back through the imports and scan source to try to find alternative logging options for django_haystack, since you're not actually that interested in the HyperKitty function which does no real work.
The thing is that phrase "no real work". Even the verbosity parameter delegates the logging to third-party code. The work here is being done by third-party code in Django and django_haystack, plus whatever indexer you're using (Whoosh or Xapian). Probably all of these have many options for logging.
If no logging is possible for those tasks, I'd consider this as an issue to fix.
Sure, but it's going to be a "patches welcome" HyperKitty issue because all HyperKitty can tell you is the command was called. Haystack can tell you that too, and a lot more. django_q (which calls the HyperKitty tasks) probably can too.
OTOH, we should document third-party logging better. Note, that doesn't require Mailman developers, non-developer contributors can do that too.