WinBoat ti ruba RAM in silenzio (anche da spento) — ecco come fermarlo
Accendi il PC, non apri niente, eppure il widget della RAM segna già 56% occupato — 36 GB usati su 64. Come è possibile? Te lo spiego passo per passo, con i comandi esatti che ho usato per trovare il colpevole e risolverlo.
ℹ️ Contesto: Questo problema riguarda chi usa WinBoat (o qualsiasi VM Windows via Docker + QEMU) su Linux. Se hai installato WinBoat e noti un consumo anomalo di RAM dopo ogni riavvio, sei nel posto giusto.
🔍 Metodo 1: Trovare il colpevole con i comandi giusti
Step 1 — Confermare che non è cache
Il primo sospetto quando la RAM sembra alta è che si tratti di cache del filesystem — Linux usa la RAM libera per mettere in cache i file letti di recente, ed è normale. Ma con questo comando capiamo subito se è cache o memoria vera:
free -h
Nell’output guarda la colonna disponibile. Se è alta (esempio: 25 GB) ma utiliz è comunque alta, allora c’è qualcosa che sta davvero occupando quella RAM — non è cache.
⚠️ Non confondere “utilizzata” con “occupata da processi”: Linux include nella RAM usata anche la cache. Il valore che conta è disponibile — se è basso, il problema è reale.
Step 2 — Trovare chi consuma di più
Ora vogliamo vedere tutti i processi in esecuzione, ordinati dal più affamato di RAM al meno. Il comando è:
ps aux --sort=-rss | head -20
Spiegazione rapida:
- 1
ps aux→ lista tutti i processi attivi sul sistema - 2
--sort=-rss→ li ordina per RAM reale usata, dal più alto (-= decrescente,rss= RAM fisica occupata) - 3
| head -20→ mostra solo i primi 20, quelli che mangiano di più
Cosa guardare: ignora tutto il resto dell’output — concentrati sulla prima riga dopo l’intestazione. Quella è il processo che usa più RAM. Nel mio caso era chiarissimo:
❌ Prima riga:
qemu-system-x86_64 ... -m 30G ... -name windows — 31,5 GB di RAM occupati da una VM Windows avviata in automatico.Step 3 — Visualizzarlo graficamente (per chi preferisce)
Se il terminale ti spaventa, puoi usare GNOME System Monitor — già installato su Ubuntu. Clicca sulla colonna Memoria per ordinare e il colpevole sale immediatamente in cima con nome e consumo in MB/GB. Perfetto per capire a colpo d’occhio.
💡 Regola d’oro: su Linux non devi leggere tutto l’output del terminale. Ordina per quello che ti interessa e guarda solo la prima riga. Il resto è rumore.
🔧 Metodo 2: Risalire alla causa e disabilitare l’avvio automatico
Step 4 — Chi ha avviato QEMU?
Sappiamo che QEMU sta girando, ma chi lo ha avviato? Ogni processo su Linux ha un “processo padre” (PPID). Con il PID trovato prima (nel mio caso 4446), eseguiamo:
ps -fp 4446
L’output mostra il PPID — il padre. Nel mio caso era il PID 3867. Lo analizziamo:
ps -fp 3867
Risultato: /usr/bin/tini -s /run/entry.sh — tini è un init minimale usato da Docker. Conferma che è un container Docker a lanciare tutto.
Step 5 — Identificare il container
docker ps
Lista tutti i container Docker attivi. Nel mio caso compariva chiaramente:
🐳 Container trovato:
WinBoat — immagine ghcr.io/dockur/windows:5.14 — avviato 21 ore prima, su da 23 minuti (ripartito da solo dopo il riavvio).Step 6 — Capire perché riparte da solo
Docker può configurare i container per riavviarsi automaticamente. Per vedere la policy:
docker inspect WinBoat | grep -A2 "RestartPolicy"
E per verificare se Docker stesso parte all’avvio del sistema:
sudo systemctl is-enabled docker
Se risponde enabled, Docker parte con il PC — e con lui tutti i container configurati per riavviarsi.
Step 7 — La soluzione: disabilitare il riavvio automatico di WinBoat
Non vogliamo disabilitare Docker (ci serve per altre cose), vogliamo solo che WinBoat non parta da solo. Un solo comando:
docker update --restart=no WinBoat
✅ Fatto. Da questo momento WinBoat non si avvierà più automaticamente ad ogni riavvio. Lo lancerai tu quando ne hai bisogno con
docker start WinBoat.📋 Cheat Sheet — Tutti i comandi in ordine
1️⃣ Verifico quanta RAM è davvero occupatafree -h
2️⃣ Trovo chi sta usando più RAM
ps aux --sort=-rss | head -20
3️⃣ Risalgo al processo padre (sostituisci 4446 con il tuo PID)
ps -fp 4446
4️⃣ Verifico il processo nonno (sostituisci 3867 con il tuo PPID)
ps -fp 3867
5️⃣ Lista container Docker attivi
docker ps
6️⃣ Controllo policy di riavvio del container
docker inspect WinBoat | grep -A2 "RestartPolicy"
7️⃣ Verifico se Docker parte all’avvio
sudo systemctl is-enabled docker
8️⃣ SOLUZIONE: disabilito avvio automatico di WinBoat
docker update --restart=no WinBoat
⚠️ Per riavviare WinBoat manualmente quando serve: docker start WinBoat
⚠️ Errori comuni e soluzioni rapide
| Problema | Causa | Soluzione |
|---|---|---|
Il comando docker ps non funziona | Docker non è installato o il servizio è fermo | Esegui sudo systemctl start docker |
| QEMU riparte ancora dopo il fix | Hai più container con policy always | Esegui docker ps -a e controlla tutti i container |
ps -fp non mostra il padre | Il processo padre è già terminato | Usa docker ps direttamente per trovare il container |
RAM ancora alta dopo docker update | Il container è ancora in esecuzione | Fermalo con docker stop WinBoat |
❓ Domande frequenti
Posso usare WinBoat normalmente dopo questo fix?
Sì, assolutamente. Cambi solo la modalità di avvio — WinBoat non parte più da solo, ma funziona esattamente come prima. Basta avviarlo manualmente con docker start WinBoat quando ne hai bisogno.
Perché WinBoat usa 30 GB di RAM?
Perché la VM Windows viene configurata con 30 GB di RAM dedicata. È una scelta di WinBoat per garantire prestazioni. Se vuoi ridurla, devi modificare la configurazione del container Docker prima di ricrearlo.
Vale solo per WinBoat o anche per altre VM?
Il metodo è universale per qualsiasi VM o container Docker che parte automaticamente. I comandi ps aux, ps -fp e docker inspect funzionano per qualsiasi processo su Linux.
Come faccio a sapere se il problema è risolto?
Riavvia il PC e dopo il boot esegui free -h — dovresti vedere la RAM occupata scendere a valori normali (3-8 GB con GNOME e le app di sistema).