Add -f (force) option to auto clean stale locks
#74
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If a local lock exists and the process is no longer running (according to the contained PID) or if a remote lock exists and was created by the same (local) host and the indicated PID is no longer running, then clean up the lock files and continue. This changes the remote locking mechanism so that the remote hostname, PID, and starting timestamp, are added to a lock file called `remote` in the tmp/lock folder on the remote host. This is meant to allow a client to detect if it is the client owning the lock file and allows it to determine if the PID which created the lock file is still running. If two clients have the same hostname, it could be possible for them to clobber each other with the `-f` option. It's up to the administrator to make sure all connecting clients have different hostnames when using this new options. A new exit status is created, `6` which indicates that the remote lock file is owned by this host and is considered stale. The `1` status is reused if it can be detected that this host is currently syncing to the host in a different PID. The `3` status is reused to indicate that another client is syncing with this remote. If the remote lock file is stale because another client crashed, then that client would have to remove the lock or it would have to be manually removed.
greezybacon
force-pushed
the
feature/lock-cleanup
branch
from
5bc646a
to
5bc8402
Compare
greezybacon
force-pushed
the
feature/lock-cleanup
branch
from
eed80a8
to
70f21a0
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If a local lock exists and the process is no longer running (according to the contained PID) or if a remote lock exists and was created by the same (local) host and the indicated PID is no longer running, then clean up the lock files and continue.
This changes the remote locking mechanism so that the remote hostname, PID, and starting timestamp, are added to a lock file called
remotein the tmp/lock folder on the remote host. This is meant to allow a client to detect if it is the client owning the lock file and allows it to determine if the PID which created the lock file is still running.If two clients have the same hostname, it could be possible for them to clobber each other with the
-foption. It's up to the administrator to make sure all connecting clients have different hostnames when using this new options.A new exit status is created,
6which indicates that the remote lock file is owned by this host and is considered stale. The1status is reused if it can be detected that this host is currently syncing to the host in a different PID. The3status is reused to indicate that another client is syncing with this remote. If the remote lock file is stale because another client crashed, then that client would have to remove the lock or it would have to be manually removed.