Hi @staff,
I am experiencing a systemic failure in n8n version 2.11.3 (Cloudron package 4.9.x) where most workflows fail to activate or execute with the following error:
libc.musl-x86_64.so.1: cannot open shared object file: No such file or directory
This appears to be a library mismatch introduced in a recent update. The error triggers specifically on nodes that utilize the JS sandbox (Merge nodes, Code nodes, etc.).
Technical findings:
I ran ldd on the isolated-vm binary inside the container, and it confirms that the module is compiled against musl (Alpine), while the Cloudron environment is glibc based (Ubuntu/Debian):
root@...:/app/code# ldd /app/code/node_modules/isolated-vm/out/isolated_vm.node
linux-vdso.so.1 (0x00007ffca68bd000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000071f4e608e000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000071f4e6060000)
libc.musl-x86_64.so.1 => not found
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000071f4e5f77000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000071f4e5d65000)
/lib64/ld-linux-x86-64.so.2 (0x000071f4e6421000)
Observed behavior:
Workflow activation fails on startup for any workflow containing a Merge or Code node.
The Python task runner also fails to start in internal mode (virtual environment missing).
Setting N8N_BLOCK_JS_SANDBOX=true does not resolve the activation errors.
It seems the latest package might have been built/bundled in an Alpine environment by mistake, or a dependency has leaked a musl requirement into the glibc image.
Could you please look into recompiling the dependencies for the current base image?