vm.stop force-kills the guest after 10 seconds; vm.reboot can leave a slow guest off
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 66/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- graphql, typescript
Direzione di ricerca
Start in api/src/unraid-api/graph/resolvers/vms/vms.service.ts, especially VmsService.setVmState, waitForDomainShutdown, and rebootVm; trace how the stop and reboot mutations handle libvirt shutdown requests and timeouts. The issue reports a 10-second polling limit followed by domain.destroy() for stop and an error for reboot. Done means slow guest shutdowns are not unexpectedly force-killed or left off after a failed reboot, while forceStop remains the hard-stop path.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Environment
Unraid OS Version: 7.4.0-rc.1 (API 4.37.5); the code is unchanged on main as of 2026-10-17.
Are you using a reverse proxy? No. Tested against the server directly.
Pre-submission Checklist
- I have verified that my Unraid OS is up to date
- I have tested this issue by accessing my server directly (not through a reverse proxy)
- This is not an Unraid Connect related issue (if it is, please submit via the support form instead)
Issue Description
vm.stop is the graceful stop (vm.forceStop is the hard one), but it doesn't stay graceful. In VmsService.setVmState (api/src/unraid-api/graph/resolvers/vms/vms.service.ts), stopping calls domain.shutdown() and then waitForDomainShutdown(), which polls 10 times at 1 second (maxRetries = 10). If the guest is not off by then, it calls domain.destroy(). Any guest that takes more than 10 seconds to shut down is powered off: Windows installing updates, Home Assistant OS, a database VM flushing to disk. The client is told the stop succeeded.
vm.reboot (rebootVm) sends the same domain.shutdown() and waits the same 10 seconds. If the guest is not off by then, it throws "Graceful shutdown failed, please force stop the VM and try again". The guest has already received the shutdown request, though, so a slow guest goes on shutting down and ends up off, not rebooted, while the client was told the reboot failed.
Steps to Reproduce
- Create a VM with no OS (nothing answers the ACPI shutdown).
- Start it, then call
mutation { vm { stop(id: "<id>") } }. - Start it again, then call
mutation { vm { reboot(id: "<id>") } }.
Expected Behavior
stopshould not destroy the domain. libvirt'sshutdown()doesn't time out on its own, sostopcould return once the request is sent, or wait longer and then return an error or a "still shutting down" result. Leave the hard stop toforceStop. A configurable or much longer timeout would also work.rebootcould usedomain.reboot()(libvirt's guest reboot), or keep waiting until the guest is off before starting it again.
Actual Behavior
- Step 2:
stopreturnedtrueafter about 10.3 s, and the domain was SHUTOFF (destroyed). - Step 3:
rebootfailed after about 10 s with the message above. The VM stayed running only because nothing inside it reacted; a real guest would have gone on shutting down.
Additional Context
Mobile and remote clients present stop as the safe option next to "force stop", and users pick it precisely to avoid data loss. Our Android client now warns users about the 10-second power cut.
- Lingua principale
- TypeScript
- Stelle
- 115
- Fork
- 23
- Merge medio
- 4g 1h
- PR unite (30g)
- 7
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di unraid/api
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
Expose per-VM details and stats on VmDomain (vCPUs, memory, disks, IPs, autostart, live usage)Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
unraid/api#2113 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 64/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
Automattic/data-liberation-agent#953 ·
I maintainer di solito rispondono entro 1 giorno
-
README に GitHub の組織のバッジを足すApertadocumentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
funmary-app/funmary#399 ·
I maintainer di solito rispondono entro 1 giorno
-
area:curator enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
CassioDalla/Scrinalia#150 ·
I maintainer di solito rispondono entro 1 giorno
-
status: needs-triage v1-bug-bash
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
a2ui-project/a2ui#3533 ·
I maintainer di solito rispondono entro 1 giorno
-
backend enhancement priority:P3
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
geolens-io/geolens#3310 ·
I maintainer di solito rispondono entro 1 giorno