Audits › Controls › Duplicate-process lock
Connection and operation · control 8 of 21
Duplicate-process lock: does your trading bot have it?
Does it prevent two instances from running at the same time, with a lockfile, a PID file, or a semaphore?
Why it matters
Two instances of the same bot double every order and fight over the same positions.
How to check it in the code
- Search for lockfile, pidfile, flock, singleton, already running.
- Check the lock is taken before the first order, not after startup.
- Check what happens when the lock is stale after a crash.
This is what the audit does for every bot in the list, on public code, without installing or running anything. Verdict values: present, partial, absent, not applicable, not verified. See the method.
Results across audited bots
Across 10 audited bots: 0 present, 3 partial, 7 absent, 0 not applicable, 0 not verified.
| Bot | Verdict | Evidence | Note |
|---|---|---|---|
| HKUDS/Vibe-Trading | Partial | agent/src/live/daily_count.py daily_order_lock(): cross-process advisory lock (fcntl on POSIX / msvcrt on Windows) per broker, wrapping the order-submission critical section; raises DailyOrderLockUnavailable if contended | Prevents concurrent order submission for the same broker from two processes, but is scoped to the order critical section, not a whole-process single-instance lock. |
| hummingbot/hummingbot | Absent | GET /search/code?q=pid_file OR lockfile OR filelock repo:hummingbot/hummingbot -> total_count 0 (2026-09-17) | No mechanism found to prevent two instances from running against the same account at once. |
| Drakkar-Software/OctoBot | Absent | GitHub code search for 'lockfile' scoped to repo:Drakkar-Software/OctoBot returned only unrelated hits (CLAUDE.md text, a web interface README) - no PID/flock/singleton mechanism (2026-09-17). | No evidence of a mechanism preventing two OctoBot instances from running against the same account simultaneously. |
| freqtrade/freqtrade | Absent | GET /search/code?q=flock+repo:freqtrade/freqtrade -> 0 results (2026-09-17); docs/advanced-setup.md 'Running multiple instances' section -- https://raw.githubusercontent.com/freqtrade/freqtrade/3774521e7028fa666770e7c7a8da323af5c4cefa/docs/advanced-setup.md | No PID file, flock or semaphore found in the codebase. The docs rely entirely on manual discipline (separate DB files, ports, Telegram bots) to avoid collisions between instances; nothing technical prevents two processes from trading the same account/DB at once. |
| jesse-ai/jesse | Partial | jesse/controllers/live_controller.py (the 'live' endpoint only rejects a request if a session with the exact same request_json.id already exists and is not in DRAFT status) + jesse/services/multiprocessing.py (ProcessManager tracks one OS process per client_id in Redis, with no dedup by exchange+symbol+route) | Two different live sessions (different IDs) trading the same exchange/symbol/route are not prevented anywhere in this code; there is no OS-level lockfile/PID file either. |
| chrisleekr/binance-trading-bot | Partial | .env.example / docs/_generated/config/env.md, WORKER_REPLICAS entry | WORKER_REPLICAS is documented to "keep at 1: multi-replica is not yet enabled (epic #561 scale-out plumbing merged but the propagation seams stay dormant at one replica)"; boot only validates the value is a positive integer (0 or non-integer aborts), it does not refuse a value >1. The README's claim of "a version-aware per-symbol state commit" (DB-level optimistic concurrency) suggests duplicate-instance order collisions may be mitigated at the data layer, but that commit-versioning code was not opened within budget to confirm. |
| alsk1992/CloddsBot | Absent | GET https://api.github.com/search/code?q=lockfile+repo:alsk1992/CloddsBot returns 1 match, in scripts/lighter-bridge/bridge.py (an unrelated Python bridge script), not the main daemon/gateway process. No PID-file or single-instance guard was found for the main bot process as of 2026-09-17. | Two instances of the gateway could plausibly run in parallel and duplicate orders; not disproven by any evidence found. |
| Lumiwealth/lumibot | Absent | GET /search/code?q=lockfile+OR+pidfile+OR+flock+repo:Lumiwealth/lumibot -> total_count: 0 (2026-09-17). | |
| YizhiSong/FriesTrader | Absent | README.md 'Running it', verbatim: 'make sure only one scheduler is ever active for a given phase -- two schedulers firing the same phase in the same cycle risks duplicate risk_check/order log entries, or duplicate real orders once execution.mode is live.' https://github.com/YizhiSong/FriesTrader#running-it | Confirmed by the author's own explicit warning, and by the full file tree containing no lockfile/PID/semaphore mechanism -- this is a stated, unmitigated gap left to the human's own scheduling discipline. |
| c9s/bbgo | Absent | no relevant match; keyword search for 'flock' across the repo returned only unrelated substring collisions (go.mod, pkg/backtest/report.go) | No lockfile/PID-file/single-instance guard was found; nothing in pkg/cmd/run.go prevents two instances from running concurrently. |
If your bot does not have it
The watchdog enforces daily loss, drawdown, position size and heartbeat limits from outside the bot, with a read-only key, whatever the bot's own code does.