12 days ago
I've included the logs from my pdf renderer service deployment and is says that an unnamed thread panicked. Weird because the service was working yesterday i didnt change the config but now it doesnt work.. even going to the older version of the code that work the issue persists.
Attachments
3 Replies
12 days ago
This thread has been marked as public for community involvement, as it does not contain any sensitive or personal information. Any further activity in this thread will be visible to everyone.
Status changed to Open Railway • 12 days ago
11 days ago
This crash is caused by the OS hitting its thread/process limit — code: 11 (EAGAIN/WouldBlock) when trying to spawn threads, which then cascades into all the NX plugin workers dying.
Root cause: The NX native Rust module (used for workspace context) is trying to spawn threads on startup, but Railway's container is hitting RLIMIT_NPROC (max processes/threads). This is a resource constraint on the container.
Why it's happening here specifically: The serve target triggers NX's project graph processing, which loads multiple plugin workers (@nx/webpack, @nx/eslint, @nx/jest, @nx/docker) simultaneously — each trying to spin up threads via the Rust native layer.
You have 3 options:
1. Disable NX Daemon and limit plugin parallelism Set these environment variables in Railway:
NX_DAEMON=false
NX_PARALLEL=12. Skip the NX project graph for serve — run the built output directly instead of going through nx run ... serve. Since webpack already compiled successfully, you can invoke node on the dist output directly:
node dist/apps/pdf-renderer-service/main.jsThis bypasses NX entirely at runtime.
3. Upgrade your Railway plan / increase container resources —The NX native module is quite thread-hungry, so you can try and increase the thread limits.
You can also try and remove packages @nx/webpack/plugin, @nx/eslint/plugin, etc. from nx.json#plugins since you only need them during local development, not when serving in production.
I recommend the 2nd option, just run the compiled output directly in Railway rather than routing through NX's serve target.
11 days ago
Another reason to go for the 2nd option is that you're running nx run @orysai-backend/pdf-renderer-service:serve:development , that runs development mode on a production server, so it's loading all extra stuff you get during development ( file watching, spawning multiple plugin workers, uses NX daemon... ), things you don't need in production.
You should build once and run the compiled output with Node.
diogoribeirodev
This crash is caused by the OS hitting its thread/process limit — code: 11 (EAGAIN/WouldBlock) when trying to spawn threads, which then cascades into all the NX plugin workers dying.Root cause: The NX native Rust module (used for workspace context) is trying to spawn threads on startup, but Railway's container is hitting RLIMIT_NPROC (max processes/threads). This is a resource constraint on the container.Why it's happening here specifically: The serve target triggers NX's project graph processing, which loads multiple plugin workers (@nx/webpack, @nx/eslint, @nx/jest, @nx/docker) simultaneously — each trying to spin up threads via the Rust native layer.You have 3 options:1. Disable NX Daemon and limit plugin parallelism Set these environment variables in Railway:NX_DAEMON=false NX_PARALLEL=12. Skip the NX project graph for serve — run the built output directly instead of going through nx run ... serve. Since webpack already compiled successfully, you can invoke node on the dist output directly:node dist/apps/pdf-renderer-service/main.jsThis bypasses NX entirely at runtime.3. Upgrade your Railway plan / increase container resources —The NX native module is quite thread-hungry, so you can try and increase the thread limits.You can also try and remove packages @nx/webpack/plugin, @nx/eslint/plugin, etc. from nx.json#plugins since you only need them during local development, not when serving in production.I recommend the 2nd option, just run the compiled output directly in Railway rather than routing through NX's serve target.
11 days ago
Thank you, had to change the path to node apps/pdf-renderer-service/dist/main.js but it worked. Thanks again!
Status changed to Solved mauro-simoes • 11 days ago