If an old PID file from a backup or prune job is left around (e.g., due to the container being killed for a server restart or something), the backup will erroneously never run due to thinking there is a running backup or prune job. Since the PID file will never get cleaned up, this blocks backups until you manually clear the PID file.
To fix this, the check just needs to be changed to check for PID file existence AND to check that the process still exists. I can make a PR for this later this week. I have an example of a check that does this that I have in another project (https://github.com/stuckj/snapdump-docker/blob/main/backup.sh#L13).
If an old PID file from a backup or prune job is left around (e.g., due to the container being killed for a server restart or something), the backup will erroneously never run due to thinking there is a running backup or prune job. Since the PID file will never get cleaned up, this blocks backups until you manually clear the PID file.
This is really my fault since I wrote the original detection in a PR for you last year (https://github.com/azinchen/duplicacy/pull/15). :-P
To fix this, the check just needs to be changed to check for PID file existence AND to check that the process still exists. I can make a PR for this later this week. I have an example of a check that does this that I have in another project (https://github.com/stuckj/snapdump-docker/blob/main/backup.sh#L13).