Rich Bell

I also am recently seeing this. I have no firm evidence, but it seems to have started after I updated the Dropbox app on my iOS devices.

As I was trying to figure out why I was seeing two `SIGKILL` from `systemctl stop`, I stumbled across this issue. Here are some ideas on possible 'fixes'. None of...

> Another approach would be similar to what `StdReport` does: save the last instance that was launched, then don't launch another until it has terminated. That way, you're guaranteed to...

> Rich, I would definitely appreciate it if you researched some solutions. It's not a big problem, but it's big enough that it's worth doing. I'm happy to some research...

tl;dr - `systemd` seems to handle sub processes that do not terminate on a SIGTERM. I have a simple WeeWX service, `testsignal`, that invokes a python program, `sleepy.py`, that runs...

You could try setting `ignore_start_time = True`. This will result in MQTTSubscribe processing the incoming data that has a time ‘prior to previous packet’. Some additional information can found here,...

Sorry, I’m not following what you are requesting. Setting the [various time configuration settings](https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Date-Time-processing#mqttsubscribeservice-processing) is for the exact situation where the time in the MQTT payload ‘cannot be trusted’.

The error message is because the driver is emitting loop packets out of order. What driver are you using? I agree its not good for WeeWX to consume the CPU,...

Current plan. If the driver emits X ‘stale’ packets in a row OR Y total ‘stale’ packets, MQTTSubscribe will shut itself down. X and Y will be configurable.

Below I have reformatted the log snippet to make what is happening more apparent. Using the log time of 19:01:39 as an example. In this one second WeeWX has dispatched...