How to fix npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed with SIGKILL in npm

npmINTERMEDIATEHIGHUpdated Dec 5, 2025· 211 views

The npm SIGKILL error occurs when the operating system forcibly terminates the npm process, typically due to out-of-memory conditions, container resource limits, or CI/CD timeouts. Unlike SIGTERM, SIGKILL cannot be caught or handled.

Quick fix

Fixes npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed with SIGKILL

# On Linux, check kernel logs
dmesg | grep -i 'out of memory\|killed process\|oom-kill'

# Or check syslog
grep -i 'oom-kill\|out of memory' /var/log/syslog

# In Docker, check container logs
docker logs <container-id> 2>&1 | grep -i killed
  1. Check system logs for OOM killer evidence
  2. Increase available memory or add swap space
  3. Optimize dependencies and build size
  4. Avoid running Node.js through npm in production
npm — error
# On Linux, check kernel logs
dmesg | grep -i 'out of memory\|killed process\|oom-kill'
# Or check syslog
grep -i 'oom-kill\|out of memory' /var/log/syslog
# In Docker, check container logs
docker logs <container-id> 2>&1 | grep -i killed
npm ERR! code SIGKILL
npm ERR! errno SIGKILL
npm ERR! process killed with SIGKILL

What this error means

The SIGKILL signal (signal 9) is an unconditional, forced termination signal sent by the operating system to immediately kill a process. Unlike SIGTERM which allows graceful shutdown, SIGKILL cannot be caught, ignored, or handled by the application—it terminates the process instantly without cleanup. When npm receives SIGKILL during installation or build operations, it indicates that something external to npm itself (the Linux kernel's OOM killer, a container orchestrator, a CI/CD system, or manual intervention) has forcibly terminated the process. This is almost never a problem with npm itself, but rather a symptom of resource constraints, timeout policies, or system-level process management decisions in your environment. The exit code 137 (128 + 9 for SIGKILL) is a reliable indicator that the process was killed by SIGKILL rather than exiting normally.

Typical symptoms

  • npm commands abruptly stop with exit code 137 (128 + 9 for SIGKILL) with no error message beyond 'Killed'
  • npm install completes nothing and exits silently without any error output
  • Docker builds fail during npm install or npm run build with no clear error messages
  • CI/CD pipelines kill npm processes after a fixed timeout period
  • Memory usage grows steadily until the process is terminated mid-operation
  • Build succeeds locally but fails in CI/CD containers or cloud deployment environments

Common causes

  1. Out of Memory (OOM): System memory is exhausted and the Linux kernel's OOM killer selects npm as the victim process
  2. Docker container memory limit exceeded: Container has insufficient RAM allocated, triggering the kernel OOM killer
  3. CI/CD timeout: Pipeline job exceeds maximum execution time and the runner sends SIGKILL
  4. Kubernetes pod termination: Pod reaches its gracePeriodSeconds timeout (default 30s) and receives SIGKILL after SIGTERM
  5. npm as parent process: Running Node.js through npm run doesn't properly relay signals, causing abrupt termination
  6. System swap unavailable: No swap space configured, causing rapid OOM killer triggers

How to fix "npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed with SIGKILL"

1Check system logs for OOM killer evidence

The first diagnostic step is to verify whether the Linux OOM killer was responsible:

bash
# On Linux, check kernel logs
dmesg | grep -i 'out of memory\|killed process\|oom-kill'

# Or check syslog
grep -i 'oom-kill\|out of memory' /var/log/syslog

# In Docker, check container logs
docker logs <container-id> 2>&1 | grep -i killed

If you see messages like "Out of memory: Kill process npm", the OOM killer is the culprit.

2Increase available memory or add swap space

Expand the memory available to npm by allocating more RAM to your container or system.

For Docker containers:

yaml
# docker-compose.yml
services:
  app:
    image: node:18
    mem_limit: 2g
    memswap_limit: 4g  # Total memory + swap

Or via command line:

bash
docker run -m 2g --memory-swap 4g node:18 npm install

For Linux systems with no swap:

bash
# Create 2GB swap file
sudo dd if=/dev/zero of=/var/swap.1 bs=1M count=2048
sudo chmod 600 /var/swap.1
sudo mkswap /var/swap.1
sudo swapon /var/swap.1
3Optimize dependencies and build size

Reduce memory consumption during npm operations:

bash
# Deduplicate dependencies
npm dedupe

# Check for outdated packages
npm outdated
npm update

# Remove node_modules and reinstall cleanly
rm -rf node_modules package-lock.json
npm install

Limit Node.js heap size explicitly during build:

bash
NODE_OPTIONS="--max-old-space-size=2048" npm run build
4Avoid running Node.js through npm in production

npm is not a process manager and doesn't properly relay signals to child processes.

In Dockerfile, replace npm with direct node execution:

dockerfile
# WRONG - npm won't relay signals properly
CMD ["npm", "start"]

# CORRECT - node handles signals directly
CMD ["node", "server.js"]

This ensures the Node process is PID 1 and receives signals directly from the system.

5Increase CI/CD job timeout limits

If SIGKILL occurs after a fixed time period, your CI/CD system is likely enforcing a timeout.

GitHub Actions:

yaml
jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 60
    steps:
      - uses: actions/checkout@v3
      - run: npm install

GitLab CI:

yaml
build:
  script:
    - npm install
  timeout: 2 hours
6Monitor memory during build

If increasing memory doesn't help, there may be a memory leak in your build process:

bash
# Monitor memory usage during npm install
watch -n 1 'ps aux | grep node | grep -v grep'

# For Docker builds, watch memory in real-time
docker stats <container-id>

# Add debug logging
node --trace-gc npm run build 2>&1 | tee build.log

Look for memory continuously increasing without recovery.

Advanced notes

Exit Code 137: When SIGKILL terminates a process, the exit code is 128 + 9 (signal number) = 137. This is different from normal failure codes and is a reliable indicator of SIGKILL.

Signal Handling Difference: SIGTERM (signal 15) allows graceful shutdown with a grace period (Kubernetes: 30 seconds, Docker: 10 seconds default). SIGKILL is always immediate—there's no opportunity for cleanup.

Container vs. System: In containerized environments, the container may have its own OOM killer separate from the host system. Setting memory limits in Docker creates cgroups that have their own OOM killer behavior.

Node.js Heap Size: The --max-old-space-size flag limits Node's garbage collection behavior, not actual system memory. A process can still be killed by the system OOM killer even if Node believes it has memory available.

Frequently asked questions

What does "npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed w" mean?
The SIGKILL signal (signal 9) is an unconditional, forced termination signal sent by the operating system to immediately kill a process. Unlike SIGTERM which allows graceful shutdown, SIGKILL cannot be caught, ignored, or handled by the application—it terminates the process instantly without cleanup. When npm receives SIGKILL during installation or build operations, it indicates that something external to npm itself (the Linux kernel's OOM killer, a container orchestrator, a CI/CD system, or manual intervention) has forcibly terminated the process.
How do I fix "npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed w"?
The npm SIGKILL error occurs when the operating system forcibly terminates the npm process, typically due to out-of-memory conditions, container resource limits, or CI/CD timeouts. Unlike SIGTERM, SIGKILL cannot be caught or handled.
What causes "npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed w"?
Out of Memory (OOM): System memory is exhausted and the Linux kernel's OOM killer selects npm as the victim process Docker container memory limit exceeded: Container has insufficient RAM allocated, triggering the kernel OOM killer CI/CD timeout: Pipeline job exceeds maximum execution time and the runner sends SIGKILL
Is the "npm ERR! code SIGKILL npm ERR! errno SIGKILL npm ERR! process killed w" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading