Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Local live deployment keeps running after SIGTERM and can be deployed twice

Offen
  • Stimmt etwas nicht?
#681 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
docker, python
Bereich
cli

Rechercherichtung

Start with lean/components/docker/docker_manager.py around DockerManager.run_image and its existing signal_handler; check how lean live deploy builds Docker run options and whether deployment lookup already exists. Reproduce termination with the commands in the issue, then verify that supported signals stop the container and repeated deployment of the same project is refused or warned about. The issue proposes separating the signal fix from labeling and duplicate checks, whose deploy-flow approach still needs confirmation.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Expected Behavior

When the lean process running a local (non-detached) lean live deploy is terminated, the LEAN container stops too, as it does on Ctrl+C. Starting a second local live deployment of a project whose deployment is still running is refused, or at least warned about.

Actual Behavior
  • DockerManager.run_image registers a handler for SIGINT only (lean/components/docker/docker_manager.py:242), and the container always runs detached. On SIGTERM or SIGHUP (closed SSH session, systemctl stop, timeout, a cancelled CI job or k8s pod) the CLI exits with 143 and the container keeps trading. Reproduced with Docker 29 on Linux.
  • lean live deploy does not look for a running container of the same project. Containers get a random lean_cli_<uuid> name, so a restart (for example a systemd unit with Restart=always, or simply running the command again after the above) starts a second algorithm on the same brokerage account.
Potential Solution
  1. Route SIGTERM and SIGHUP (where available) through the existing signal_handler, so they stop the container like Ctrl+C.
  2. Label LEAN containers with the project path or id, the environment and the brokerage (labels in run_options).
  3. In live deploy, look up running containers with the same project label and refuse with a clear message, offering lean live stop <project> or a --force flag.

Step 1 is small and I can open it as a PR first. Steps 2 and 3 change the deploy flow, so I'd like to confirm the approach before writing them.

Reproducing the Problem
lean live deploy MyProject --brokerage "Paper Trading" ... &
kill -TERM $!
docker ps --filter name=lean_cli_   # the container is still running
lean live deploy MyProject --brokerage "Paper Trading" ...   # a second container starts
System Information

lean-cli master at b4d724c, Python 3.12, Linux, Docker 29.

Checklist
  • I have completely filled out this template
  • I have confirmed that this issue exists on the current master branch
  • I have confirmed that this is not a duplicate issue by searching issues
Vorherrschende Sprache
Python
Sterne
327
Forks
170
Ø Merge
8 T. 14 Std.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus QuantConnect/lean-cli

Alle Issues in QuantConnect/lean-cli

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.