[phildapunk]

Fixes #801.

The problem

Start Library Monitor Service has never actually started the background service on macOS. The service's running/singleton lock is a POSIX named shared-memory segment:

SHAREDMEMORY_NAME = "DavidMaisonaveAxter_FileMonitor" # 31 chars

macOS's shm_open() rejects names longer than PSHMNAMLEN (31 chars, including the leading / that multiprocessing.shared_memory prepends on POSIX). This name is exactly 31 characters, so with the slash it's 32 — one over the limit:

>>> from multiprocessing import shared_memory
>>> shared_memory.SharedMemory(name="DavidMaisonaveAxter_FileMonitor", create=True, size=10)
OSError: [Errno 63] File name too long: '/DavidMaisonaveAxter_FileMonitor'

The except: around that call swallows the exception and logs a generic "must already be running" message, so the real cause never showed up in the log — just the same misleading line on every attempt, for well over a year of this user's filemonitor.log history.

What this does

• Shorten SHAREDMEMORY_NAME to 26 characters. Verified empirically on current macOS that 30 chars succeeds and 31 fails, so this has headroom.
• Log the real exception in the existing error message, so if this ever regresses (e.g. a future rename back over the limit) it's visible instead of misdiagnosable.
• Harden executeProcess()'s detach path, shared byte-for-byte across FileMonitor, DupFileManager, and RenameFile's StashPluginHelper.py: pass start_new_session=True when detaching, so the spawned child survives the launching task process exiting. The code already carried a comment flagging this was needed on macOS (# On detach, may need the following for MAC OS ... start_new_session=True) but never applied it.

Testing

Against a live Stash instance running natively on macOS (not Docker):

• Before: clicking "Start Library Monitor Service" logged a spawned pid and "transitioning to service mode", but Settings → Tools → FileMonitor immediately reported FileMonitor is NOT running!!! — reproduced on every attempt.
• After: reproduced the exact OSError directly against multiprocessing.shared_memory with the old name, confirmed the new name succeeds up to 30 chars, applied the fix, reloaded the plugin in Stash, started the service, and confirmed Settings → Tools → FileMonitor now reports running.

Scope

Only touches filemonitor.py's shared-memory name/error message, and the identical executeProcess() block in all three vendored StashPluginHelper.py copies. Bumped each plugin's version (FileMonitor 1.0.7→1.0.8, DupFileManager 1.0.2→1.0.3, RenameFile 1.0.4→1.0.5) since StashPluginHelper.py changed in all three, and added a FileMonitor version_history entry.

LLM-assisted contribution disclosure

Per the repository's contribution policy: this change was prepared with LLM assistance (Claude). The diff has been reviewed by me, the testing described above was carried out and its results are reproduced verbatim, and I take full responsibility for the change and its license compliance.

[phildapunk]

Follow-up found while verifying the first commit end-to-end: once the shared-memory rename took effect, the service genuinely started and kept running (confirmed via a live `ps` check), but the very first "Tools -> FileMonitor" status check flipped every status check after it to "NOT running" — even though the process was still alive and logging its watch loop.

Cause: both `getFileMonitorRunningStatus()` and `start_library_monitor_service()`'s own "already running" pre-flight guard open the shared-memory lock with `create=False` just to confirm it exists, then call `shm_a.unlink()` on success. `unlink()` deletes the named segment from the OS immediately; the running service keeps its own already-open mapping and is unaffected, but the name is gone, so every later status check (and `stop_library_monitor()`, and the "already running" duplicate-start guard) can no longer find it by name.

Added a second commit that removes the unlink from both of those read-only checks — only `stop_library_monitor()` (which is actually supposed to tear the lock down) still unlinks. Verified by killing the now-orphaned process (whose lock had already been destroyed by the old code before this fix landed), restarting the service, and confirming repeated status checks now consistently report "running".

[phildapunk]

Second follow-up: removing the explicit `unlink()` calls in the previous commit wasn't actually enough — it still went back to "NOT running" ~8-15s after a successful check. Reproduced the real mechanism in isolation (3-process repro: a creator that holds the segment, a separate attacher that opens it `create=False` and exits cleanly, then a checker): the attacher's own `resource_tracker` treats the segment as "leaked" on its own exit and unlinks it — regardless of `unlink()` never being called explicitly, and regardless of the real creator still being alive. This is a known `multiprocessing.shared_memory` gotcha; the fix is calling `resource_tracker.unregister(shm._name, "shared_memory")` right after a read-only attach, in both `getFileMonitorRunningStatus()` and `start_library_monitor_service()`'s "already running" guard. Verified the failure mode and the fix in isolation before applying, then re-tested end-to-end against the same live instance.

[DogmaDragon]

Please limit the PR to a single plugin.

[phildapunk]

Done — pushed a commit that drops the DupFileManager and RenameFile changes. This PR is now scoped to FileMonitor only. I'll open the same start_new_session=True detach fix for DupFileManager and RenameFile as separate single-plugin PRs.

[discourse-stashapp]

This pull request has been mentioned on Stash Forum. There might be relevant details there:

https://discourse.stashapp.cc/t/filemonitor/1333/13