The code is still there. max_wait defaults to 60s, so it will start another
report cycle after 10m (assuming max_wait is overrridden somewher).
def launch_report_thread(self, _event):
"""Called after the packet LOOP. Processes any new data."""
import weewx.reportengine
# Do not launch the reporting thread if an old one is still alive.
# To guard against a zombie thread (alive, but doing nothing) launch
# anyway if enough time has passed.
if self.thread and self.thread.is_alive():
thread_age = time.time() - self.launch_time
if thread_age < self.max_wait:
log.info("Launch of report thread aborted: existing report
thread still running")
return
else:
log.warning("Previous report thread has been running"
" %s seconds. Launching report thread anyway.",
thread_age)
try:
self.thread = weewx.reportengine.StdReportEngine(self.config_dict,
self.engine.stn_info,
self.record,
first_run=not
self.launch_time)
self.thread.start()
self.launch_time = time.time()
except threading.ThreadError:
log.error("Unable to launch report thread.")
self.thread = None
> On Aug 4, 2026, at 5:24 AM, matthew wall <[email protected]> wrote:
>
> i might be hallucinating, but i remember at one point the code that starts
> reports would check to see if a report was still running. if the report was
> still running, it would skip that report and go to the next, with a log entry
> that the report was skipped.
>
> a quick scan of reportengine.py does not show any of that behavior, so i must
> be remembering logic from a previous implementation or something that never
> made it to master.
>
> a per-report mutex/lock could be done in reportengine.py. but it might be
> better to do it within each report, since the report has more detail (and
> could thus provide better logs) about what is happening.
>
> i suppose that starting a thread for each report could lead to much
> complexity if reports try to write to the database, not just read from it
>
> there have *always* been issues with shutting down the reporting thread. if
> something in the report thread has a unresponsive file handle open (e.g.,
> slow nfs link) or a network socket open, then the thread does not shut down
> immediately when the engine does a shutdown.
>
> m
>
> --
> You received this message because you are subscribed to the Google Groups
> "weewx-user" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion visit
> https://groups.google.com/d/msgid/weewx-user/C69E9E4C-0B2F-44E8-B437-75990351E842%40gmail.com.
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/weewx-user/A474BB64-408D-4CEB-A198-FF1CA57381F7%40johnkline.com.
