Reset Mutex (Issue 2429) (#2460)

Force the Mu-tex to reset if it's being held by a zombie process

If a process crashes hard before releasing the Mu-tex then a new process won't be able to start. (This is only likely to happen on Linux which doesn't automatically release the shared memory we use to implement the mutex).

This PR always attaches and detaches from the shared memory before checking whether or not it can attach and read the contents. This is enough to take control of the mutex from the zombie process

Makefile

@@ -60,7 +60,7 @@ coverage: clean
 	export LANG=en_GB.utf8
 	pytest -v --random-order --cov-config setup.cfg --cov-report term-missing --cov=mu tests/
 
-tidy: 
+tidy:
 	python make.py tidy
 
 black:

mu/app.py

@@ -297,6 +297,16 @@ def __exit__(self, *args, **kwargs):
         self._shared_memory.unlock()
 
     def acquire(self):
+        #
+        # The attach-detach dance is a shim from
+        # https://stackoverflow.com/questions/42549904/qsharedmemory-is-not-getting-deleted-on-application-crash
+        # If the existing shared memory is not held by any active application
+        # (eg because an appimage has hard-crashed) then it will be released
+        # If the memory is held by an active application it will have no effect
+        #
+        self._shared_memory.attach()
+        self._shared_memory.detach()
+
         if self._shared_memory.attach():
             pid = struct.unpack("q", self._shared_memory.data()[:8])
             raise MutexError("MUTEX: Mu is already running with pid %d" % pid)
@@ -354,7 +364,6 @@ def run():
     logging.info("Platform: {}".format(platform.platform()))
     logging.info("Python path: {}".format(sys.path))
     logging.info("Language code: {}".format(i18n.language_code))
-
     setup_exception_handler()
     check_only_running_once()
 

setup.cfg

@@ -23,6 +23,7 @@ exclude =
     ./.venv*/
     ./env/
     ./.env/
+    ./local-scripts/
 max-line-length = 88
 
 [coverage:run]