[68] Improve lockfile handling - #114
Draft
Lagejohn wants to merge 8 commits into
Draft
Conversation
…acking UUIDs to PIDs
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| public static boolean isPidRunning(String pid) { | ||
| try { | ||
| Process process = Runtime.getRuntime().exec( | ||
| new String[]{"kill", "-0", pid} // kill -0 returns exit code 0 if process exists, doesn't send any signals |
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Instead of a lockfile containing a random hash, MMTC now creates a lockfile based on its current process ID. If it encounters an existing lockfile during initialization, it will check if the parent process of that lockfile is still running, and if not, safely removes it as a stale file from a since-cancelled run of MMTC. If the process IS still running, then it's considered an existing active instance of MMTC and the new instance will refuse to start.
This is designed to handle cases where MMTC terminated prematurely before its lockfile could be removed, preventing new runs from starting until the user manually deletes the lockfile.
Draft until manual testing is complete.
Test 1 (nominal case): Two consecutive runs are executed to verify successful acquisition and release of lockfile:
Result: no logged warnings about existing lockfile on second run as expected
Test 2: MMTC aborted after lock file has been acquired but before time correlation could complete; second run then reattempted:
Result: Second run detects and warns of stale lock file but still completes successfully.
Test 3: Second instance of MMTC started while a prior instance was still running:
Result: Second instance detects lockfile belonging to active process and refuses to start.
Test 4: MMTC started with intentionally corrupted/invalid lockfile already in place:
Result: MMTC cannot determine if the lockfile PID is running and throws as expected.