Ignore own parent process when detecting other Rally processes - #2163
Ignore own parent process when detecting other Rally processes#2163lowbyteguy wants to merge 1 commit into
Conversation
If the process that launches Rally is itself a Python process whose command line mentions esrally (for example a VS Code debugpy launcher, or a wrapper script), is_rally_process() matches it and Rally refuses to start, reporting its own parent as a conflicting instance. for_all_other_processes() already skips the current PID; it now skips the parent PID as well, so launchers are no longer mistaken for competing Rally instances. Genuine concurrent Rally processes are still detected. Closes elastic#2026
|
❌ Author of the following commits did not sign a Contributor Agreement: Please, read and sign the above mentioned agreement if you want to contribute to this project |
There was a problem hiding this comment.
Pull request overview
Fixes a false-positive in Rally’s “other Rally processes” detection when Rally is launched by a Python parent process (e.g., VS Code debugpy launcher) whose command line mentions esrally, causing Rally to think a conflicting instance is running.
Changes:
- Update process iteration helper to skip the parent PID in addition to the current PID when scanning for “other” processes.
- Add a regression test that simulates a Python launcher parent process mentioning
esrallyand verifies it is ignored.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
esrally/utils/process.py |
Skips the parent PID during process iteration to avoid detecting the launcher as a conflicting Rally process. |
tests/utils/process_test.py |
Adds a unit test covering the launcher-parent false-positive scenario. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| def for_all_other_processes(predicate: Callable[[psutil.Process], bool], action: Callable[[psutil.Process], None]) -> None: | ||
| # no harakiri please | ||
| my_pid = os.getpid() | ||
| # the process that launched us is not a competing Rally process either, even if its command line | ||
| # happens to mention Rally (e.g. a debugger or wrapper script that invokes esrally) | ||
| my_ppid = os.getppid() | ||
| for p in psutil.process_iter(): | ||
| try: | ||
| if p.pid != my_pid and predicate(p): | ||
| if p.pid not in (my_pid, my_ppid) and predicate(p): | ||
| action(p) |
pquentin
left a comment
pquentin
left a comment
There was a problem hiding this comment.
I haven't reviewed it explicitly yet (only added an upvote), but I think the Copilot comment is correct: it's not that easy. There's also the question of the interaction with rallyd. I'd be interested to see an analysis of this, maybe done by an LLM initially.
Closes #2026
If the process that launches Rally is itself a Python process whose command line mentions
esrally(a VS Codedebugpylauncher, or a wrapper script),is_rally_process()matches it, so Rally reports its own parent as a conflicting instance and refuses to start.for_all_other_processes()already skips the current PID; it now skips the parent PID too. Genuine concurrent Rally processes are still detected, and a regression test intests/utils/process_test.pycovers the launcher case.Ran
tests/utils/process_test.py(7 passed); the new test fails without theprocess.pychange.