Corrección del error 'No space left on device' en AWS Amplify Sandbox en Linux

Terminal del sandbox de AWS Amplify con el error inotify_add_watch 'No space left on device' y la corrección con sysctl

Si estás ejecutando AWS Amplify Gen 2 sandbox en Linux y encuentras este error críptico, no estás solo:

[Error] inotify_add_watch on '/home/code/Documents/DevCourses/back-to-fluency-ai/amplify/auth/post-confirmation/node_modules/@aws-amplify/data-construct/node_modules/@aws-amplify/ai-constructs/node_modules/@aws-sdk/types/node_modules/@smithy/types/dist-types/ts3.4/blob' failed: No space left on device

El mensaje de error es engañoso - esto no tiene nada que ver con el espacio en disco. Tu disco duro podría estar completamente vacío y seguirías viendo este error.

El verdadero problema: observadores de inotify

El sandbox de Amplify usa observadores de archivos para detectar cambios en tu código e implementar automáticamente. En Linux, la observación de archivos se maneja mediante el sistema inotify, que tiene un límite en cuántos archivos pueden monitorearse simultáneamente.

Los proyectos modernos de JavaScript con dependencias node_modules profundamente anidadas pueden exceder fácilmente este límite. En el error anterior, puedes ver que la ruta atraviesa múltiples carpetas node_modules anidadas - cada una agregando al contador de observadores.

La corrección rápida

Verifica tu límite actual:

cat /proc/sys/fs/inotify/max_user_watches

Probablemente verás algo como 8192 o 65536 - no es suficiente para un proyecto grande.

Corrección temporal (hasta reiniciar)

sudo sysctl fs.inotify.max_user_watches=524288

Esto aumenta el límite a 524,288 observadores, lo que debería ser más que suficiente para la mayoría de los proyectos.

Corrección permanente

Para que este cambio persista entre reinicios:

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

Esto agrega la configuración a /etc/sysctl.conf y recarga la configuración.

Alternativa: excluir node_modules de la observación

Si no quieres (o no puedes) aumentar el límite del sistema, puedes decirle a Amplify que ignore node_modules:

npx ampx sandbox --exclude "**/node_modules/**"

Esto tiene sentido porque:

  • Rara vez modificas archivos dentro de node_modules durante el desarrollo
  • Las dependencias no cambian a menos que ejecutes npm install
  • Excluirlas reduce drásticamente el número de observadores necesarios

Puedes agregar esto a tus scripts de package.json por conveniencia:

{
  "scripts": {
    "sandbox": "ampx sandbox --exclude '**/node_modules/**'"
  }
}

Luego simplemente ejecuta:

npm run sandbox

Por qué sucede esto

El límite de inotify existe para prevenir que procesos descontrolados consuman demasiados recursos del kernel. Sin embargo, los límites predeterminados se establecieron hace años cuando los proyectos eran mucho más pequeños.

Las herramientas modernas de JavaScript crean árboles de dependencias profundamente anidados. Un único npm install puede crear miles de archivos en múltiples carpetas node_modules anidadas. Cuando herramientas como Amplify sandbox, servidor de desarrollo Next.js, modo watch de Jest, o Webpack intentan observar todos estos archivos, rápidamente alcanzan el límite.

Otras herramientas afectadas

Este no es solo un problema de Amplify. Podrías ver errores similares con:

  • Next.js: ENOSPC: System limit for number of file watchers reached
  • Jest: Error: ENOSPC: System limit for number of file watchers reached
  • Webpack: Error: ENOSPC: System limit for number of file watchers reached
  • VS Code: La observación de archivos puede dejar de funcionar

La corrección es la misma para todos ellos - aumenta el límite de inotify.

Verificación de tu uso actual

¿Quieres ver cuántos observadores estás usando actualmente?

# Count watchers per process
for foo in /proc/*/fd/*; do readlink -f $foo; done | grep inotify | sort | uniq -c | sort -nr

# Total watchers in use
find /proc/*/fd/* -type l -lname 'anon_inode:inotify' 2>/dev/null | wc -l

Esto te ayuda a entender si estás cerca del límite y necesitas aumentarlo.

Límites recomendados

Tamaño de proyectoLímite recomendado
Proyectos pequeños65536
Proyectos medianos262144
Proyectos grandes (como aplicaciones Amplify Gen 2)524288
Monorepos muy grandes1048576

El overhead de memoria es mínimo - cada observador usa aproximadamente 1KB de memoria del kernel, así que incluso 524,288 observadores solo usan ~512MB.

Resumen

Cuando ves errores "No space left on device" con Amplify sandbox (u otras herramientas de desarrollo) en Linux:

  1. No se trata de espacio en disco - se trata de límites de observadores de inotify
  2. Aumenta el límite con sudo sysctl fs.inotify.max_user_watches=524288
  3. Hazlo permanente agregando a /etc/sysctl.conf
  4. O excluye node_modules de la observación con --exclude "**/node_modules/**"

Esta corrección también ayudará con Next.js, Jest, Webpack y otras herramientas que usan observación de archivos.


¿Enfrentándote a otros problemas de Amplify Gen 2? ¡Consulta nuestras otras guías de solución de problemas!

  • No se puede resolver amplify_outputs.json

    Para corregir el error de compilación "no se puede resolver amplify_outputs.json", añade npx ampx pipeline-deploy --branch $AWS_BRANCH --app-id $AWS_APP_ID a la configuración de compilación y adjunta la política AdministratorAccess-Amplify

  • Corrección de errores 'Could not resolve' para dependencias de funciones Lambda en AWS Amplify Gen 2.

    Las funciones Lambda con su propio package.json necesitan dependencias instaladas antes de que esbuild las empaquete. Agrega una fase preBuild a amplify.yml que ejecute npm ci en cada directorio de función. También excluye amplify/**/* de tu tsconfig.json raíz.

  • Desplegar una app fullstack de Next.js 16 en AWS Amplify Gen 2 (SSR): seis fallos y cómo evitarlos

    Llevar una app de Next.js 16 con un backend de Amplify Gen 2 a Amplify Hosting SSR costó seis compilaciones fallidas — cada una revelando una capa más profunda que la anterior. Esta es la cadena completa: desincronización del lockfile, el límite de 220 MB de cómputo, el callejón sin salida de la especificación de despliegue, un binario xz ausente, un usuario de compilación sin permisos de root y una incompatibilidad entre layer y runtime — con la solución de cada uno.