n8n crashes with SIGILL (exit code 132) during PDF extraction – invalid opcode in skia.linux-x64-musl.node

[PinguIntel]

Summary

When executing a workflow that extracts text from a PDF, the n8n process crashes hard and is restarted by Docker. In the UI this appears as “Connection lost” while the workflow or sub-workflow is running. After ~1 minute, the editor reconnects because the container has restarted.

This is not a memory exhaustion issue. The root cause is a native crash (SIGILL) in skia.linux-x64-musl.node.

Environment

• n8n version: 2.0.0
• Docker image: docker.n8n.io/n8nio/n8n:2.0.0
• Deployment: Docker Compose
• Host OS: Ubuntu 24.04LTS running in a VM on Proxmox
• CPU type: host
• Reverse proxy: Caddy
• Database: SQLite
• Binary data mode tested: filesystem

What happens

1. A workflow (or sub-workflow) extracts text from a PDF.
2. The PDF is small (~600 KB).
3. During execution:
   • The editor shows “Connection lost”
   • Opening the sub-workflow returns a GET error
4. ~60 seconds later, the editor reconnects.
5. Docker shows the container has restarted.

Evidence (hard crash, not OOM)

Docker container exits with SIGILL:
exitCode=132

Docker events:
container die ... exitCode=132

Kernel logs (dmesg):
trap invalid opcode ... in skia.linux-x64-musl.node

This happens consistently when the PDF extraction path is hit.

Why this is NOT a memory issue

I explicitly tested and ruled out memory exhaustion:

• Increased Node heap:
  NODE_OPTIONS=--max-old-space-size=4096
• Verified the host has ample free RAM
• Docker reports:
  oomkilled=false
• PDF size is small (~600 KB)

Despite this, the process still crashes with SIGILL, which points to an illegal CPU instruction in a native module, not memory pressure.

What I tried

• Increased Node.js heap size
• Switched binary data handling to filesystem mode:
  N8N_DEFAULT_BINARY_DATA_MODE=filesystem
• Confirmed VM CPU type is already host
• Confirmed Docker is not applying memory limits
• Confirmed the crash occurs specifically during PDF extraction
• Reproduced the issue multiple times with consistent results

None of the above prevented the crash.

Impact

• Any workflow using PDF extraction can crash the entire n8n instance
• Active workflows are interrupted
• UI becomes temporarily unusable
• This makes the built-in PDF extraction node unsafe in production on musl-based images

Suspected root cause

The Alpine/musl build of Skia (skia.linux-x64-musl.node) appears to execute unsupported CPU instructions on some systems, causing a SIGILL and terminating the Node.js process.

This matches:

• exitCode=132
• trap invalid opcode
• crash + immediate container restart

Possible Workarounds

• Did not test: Run n8n on a Debian/glibc-based image (avoids musl Skia)
• Did not test: Avoid the built-in PDF extraction node and offload PDF parsing to an external service/different node

However, neither should be required for a standard n8n workflow.

To Reproduce

Steps to Reproduce

1. Deploy n8n using the official Docker image:
   docker.n8n.io/n8nio/n8n:2.0.0 (Alpine/musl-based)

2. Start n8n via Docker Compose with a standard setup (SQLite, no special memory limits).

3. Create a workflow that:

   • Receives or downloads a PDF file (binary data)
   • Uses the built-in PDF extraction node (e.g. “Extract from PDF” / equivalent)

4. Use a small PDF file (~600 KB is sufficient).

5. Execute the workflow (or call it as a sub-workflow).

6. Observe:

   • The editor UI shows “Connection lost”
   • Opening the sub-workflow returns a GET error
   • After ~1 minute, the editor reconnects

7. Check Docker / host logs:

   • The n8n container has restarted
   • Docker reports exitCode=132
   • dmesg shows:
     trap invalid opcode ... in skia.linux-x64-musl.node

Expected behavior

Extracting text from a PDF should not crash the n8n process, regardless of PDF size, and should fail gracefully if an error occurs.

Debug Info

Debug info

core

• n8nVersion: 2.0.0
• platform: docker (self-hosted)
• nodeJsVersion: 22.21.0
• nodeEnv: production
• database: sqlite
• executionMode: regular
• concurrency: -1
• license: enterprise (production)
• consumerId: 7ad3fa35-7559-46e9-bbe8-da6bf8615fa4

storage

• success: all
• error: all
• progress: false
• manual: true
• binaryMode: filesystem

pruning

• enabled: true
• maxAge: 336 hours
• maxCount: 10000 executions

client

• userAgent: mozilla/5.0 (x11; linux x86_64) applewebkit/537.36 (khtml, like gecko) chrome/143.0.0.0 safari/537.36
• isTouchDevice: false

Generated at: 2025-12-31T08:14:49.331Z

Operating System

Ubuntu 24.04

n8n Version

2.0.0

Node.js Version

22.21.0

Database

SQLite (default)

Execution mode

main (default)

Hosting

self hosted

[n8n-assistant]

Hey @PinguIntel,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-6104".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-6104

[leolionart]

I'm also experiencing the same problem, even after updating to the latest version. What's strange is that it doesn't happen when n8n is installed on a different server. The server's specifications are not low either.

[krisn0x]

Hey @PinguIntel This is possibly related to #19359, can you test the custom image there and let us now if it changes anything?

[Drewcoder789]

Hi @krisn0x !

I’m exploring contributing to n8n and wanted to clarify which issues are best for community contributors to pick up.

I noticed many merged PRs reference Linear tickets, and I understand those are created and tracked internally. Since I don’t have access to Linear, I wanted to ask which GitHub issues are appropriate for external contributors to work on.

Specifically, is it okay for contributors to pick issues with labels like status:in-linear, status:pending-assignment, or triage:complete?
Are there any labels you recommend prioritizing (or avoiding) when choosing an issue to work on?

Thanks a lot for your time and for maintaining the project. Looking forward to contributing!