Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#681 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
docker, python
Ambito
cli

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
Python
Stelle
327
Fork
170
Merge medio
8g 14h
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di QuantConnect/lean-cli

Tutte le issue di QuantConnect/lean-cli

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.