feat(episode): BACKFILL_q-1811e986-7f1f-40af-afe0-8cd0bfe7ccbe_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.83461_E.38B-C

Skill: NONE | Type: chronicle
Summary: Exit code -1 en Docker corresponde al signal SIGKILL (signal 9) — el proceso fue

episodes/BACKFILL_q-1811e986-7f1f-40af-afe0-8cd0bfe7ccbe_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.83461_E.38B-C.md

@@ -0,0 +1,19 @@
+---
+episode_id: "8346138b-c1c1-5e31-8127-4886b6ebdb5e"
+puente_flat: "BACKFILL_q-1811e986-7f1f-40af-afe0-8cd0bfe7ccbe_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.83461_E.38B-C"
+session_code: "S20260510.BACKFILL_RECOVERED"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "Exit code -1 en Docker corresponde al signal SIGKILL (signal 9) — el proceso fue terminado por el kernel, no por error propio. La causa más probable es el OOM Killer (Out-Of-Memory Killer) del kernel"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+Exit code -1 en Docker corresponde al signal SIGKILL (signal 9) — el proceso fue terminado por el kernel, no por error propio. La causa más probable es el OOM Killer (Out-Of-Memory Killer) del kernel Linux, que termina procesos cuando el sistema queda sin memoria disponible. El troubleshooting tiene que ir a nivel kernel, no a nivel del container. El siguiente comando verifica si el OOM Killer es el responsable: ```bash # Buscar en dmesg menciones del OOM Killer matando qdrant-recovery sudo dmesg --since "24 hours ago" | grep -E "(oom|OOM|killed|kill)" | tail -30 ``` Si el OOM Killer mató el proceso, dmesg mostrará líneas del tipo: `Out of memory: Killed process XXXX (qdrant) score YYY or sacrifice child`. --- Ember (2026-04-06 09:19): Confirmado — el OOM Killer terminó el proceso `qdrant` con score 687. El OOM score de 687 indica que el proceso `qdrant-recovery` estaba consumiendo ~68.7% de la memoria total del servidor MEMORIA CX53 antes de ser terminado. El siguiente comando muestra el uso de memoria por container en tiempo real: ```bash docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}\t{{.CPUPerc}}" ``` También hay que verificar si `qdrant-recovery` tiene `mem_limit` configurado en su docker-compose. Un container sin `mem_limit` puede consumir toda la RAM disponible del servidor — la regla es que TODO container de producción en MEMORIA CX53 debe tener `mem_limit` explícito. --- Ember (2026-04-06 09:24): La causa raíz está clara. La diagnosé en tres capas: **Capa 1 (kernel):** El OOM Killer terminó el proceso porque el servidor llegó a un estado de memoria insuficiente. El OOM score de 687 de `qdrant-recovery` refleja su consumo desproporcionado de RAM (18.2GB de 32GB = 56.9%). **Capa 2 (container):** El container `qdrant-recovery` NO tenía `mem_limit` configurado. La solución inmediata es agregar `mem_limit: 4g` al servicio `qdrant-recovery` en su docker-compose. **Capa 3 (correlación con PG):** La query lenta de 8000ms en la tabla `embeddings` es correlacionada pero NO es la causa raíz. Los siguientes comandos aplican el fix: ```bash # Opción A: aplicar límite en caliente docker update --memory 4g --memory-swap 4g qdrant-recovery # Opción B: recrear con mem_limit en docker-compose cd /home/johnember/docker/qdrant-recovery/ # Agregar mem_limit: 4g en el docker-compose.yml y recrear docker compose up -d --force-recreate qdrant-recovery # Verificar que el límite se aplicó docker inspect qdrant-recovery | grep -A2 '"Memory"' ``` VERIFICADO: `docker update --memory` aplica el límite sin downtime en Linux con cgroups v2 (Ubuntu 24.04 en MEMORIA CX53). La restricción es...