Lock file prevents syncing even with old invalid pid

[robspearman]

Describe the bug
If a sync is interrupted, the lock file with an out of date pid remains in the filesystem. (Worst case is that a user unplugs a USB drive during a sync or power is lost.)

To Reproduce
Steps to reproduce the behavior:

1. Have a directory to sync with an osync working directory "lock" file with an old pid.
2. Try to sync and get fatal error that "There is already a local instance"...

Expected behavior
If there is no actual osync process matching the lock file pid then the error is incorrect and the real issue is that the last sync did not complete, and different logic should apply (give correct warning, retry, etc.).

Desktop (please complete the following information):
Linux.

Additional context
I am trying to protect against non-technical users getting themselves stuck.

[deajan]

Sorry for the (very) late answer.
Have you tried setting FORCE_STRANGER_LOCK_RESUME=true in config ?

The logic seems good to me (

osync/osync.sh

Line 3148 in 8451024

RemoteLogger "There is a remote dead osync lock [$lockPid@$lockInstanceID] on target replica that corresponds to this initiator INSTANCE_ID. Pid [$lockPid] no longer running. Resuming." "NOTICE"

) unless you use a different INSTANCE_ID than the previous sync. That's the case for which the above setting is designed for.