MAVproxy >= 1.8.66 causes exception in thread log_writer on exit

[dbstf]

Platform: RaspberryPi, aarch64, kernel 6.1.21-v8+ Python 3.11.2 numpy 2.0.0 (also tested with 1.26.4 --> same error)

Starting mavproxy script with either python3 mavproxy.py --master=/dev/serial0 --baudrate=921600, or python3 mavproxy.py --master=/dev/serial0 --baudrate=921600 --cmd='set requireexit True', respectively.

When trying to exit the script with either Ctrl-C or entering exit, respectively, MAVproxy version >= 1.8.66 is throwing the following exception:

Exception in thread log_writer:
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1038, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.11/threading.py", line 975, in run

and

Exception in thread log_writer:
Traceback (most recent call last):
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x0057a4c8)

Current thread 0xf7b57040 (most recent call first):
  <no Python frame>

Extension modules: numpy._core._multiarray_umath, numpy._core._multiarray_tests, numpy.linalg._umath_linalg (total: 3)

There is no exception when using MAVproxy version <= 1.8.62 (Versions available via pip install: ..., 1.8.62, 1.8.66, 1.8.67, 1.8.68, 1.8.69, 1.8.70)

[Ryanf55]

This prevents MAVProxy from exiting cleanly. It needs to be sigtermed. MAVProxy does not respect ctrl+C properly, even in the most basic use case.

[Ryanf55]

https://discuss.python.org/t/getting-rid-of-daemon-threads/68836

According to the python maintainers, the recommended approach is to not use daemon threads. https://docs.python.org/3/library/threading.html#thread-objects

It recommends instead using e threading Event to signal.

[flyasky]

+1 exit by Ctrl+D on windows

Exception in thread log_writer:
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x00007ff8f3dcdd50)

Current thread 0x000052f4 (most recent call first):
  <no Python frame>