bullmq
bullmq copied to clipboard
[Bug]: multiple open msgpackr processes after terminating a node.js process that uses bullmq
Version
v4.8.0
Platform
NodeJS
What happened?
After closing a node process that uses BullMQ multiple msgpackr processes remain open and consume a lot of cpu. The only dependency on msgpackr in my project is from BullMQ.
All the node processes details are the same as above:
How to reproduce.
Use the latest version of bullmq and make it so that the Redis connection fails and ioredis tries to retry the connection.
After closing the node.js process using ctrl+c, many unused msgpackr processes will not terminate and start to consume all of your system's resources.
I provide a single ioredis connection to all of my queues and workers.
Relevant log output
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Are you sure about this? reason for asking is that in Unix, if the parent process is killed, its children are killed automatically, so it is strange that you still have node processes running after killing the parent.
Yes, my basic understanding was the same as yours but this is the situation I'm dealing with.
I use a nodemon-like process manager to restart the server automatically but my server will not restart when connection to Redis fails so I don't think nodemon is the issue. I just found out that there will be orphan processes with msgpackr running regardless of the Redis connection status.
My main suspect is msgpackr as it is a native node.js C++ addon (binary) and these addons tend to generate such issues. Somehow SIGKILL does not reach the processes created by msgpackr.
I even suspect that there may be some malware in msgpackr trying to mine crypto or something else. 😄
I'll investigate further when I have more free time.
What makes you believe msgpackr is creating this issue? BTW; it is just plain javascript: https://www.npmjs.com/package/msgpackr
Sorry, I was not specific enough, the processes that stay open all belong to msgpackr-extract which is a dependency of msgpackr package.
Please take a look at the screenshot. msgpackr depends on msgpackr-extract package that is in binary format specifically: msgpackr-extract-darwin-arm64/node.napi.glibc.node.
I see, it states that it is an optional dependency but it is enabled by default: https://www.npmjs.com/package/msgpackr
Are you using sandboxed processors or standard?
We are using the standard processors.
In order to be able to investigate this issue further we would need some simple test that we can run to reproduce it.
Actually, I don't know a good way to provide you with a MacOS sandbox. I can confirm this only happens in MacOS.
@HosseinAgha I am on Mac. What piece of test code should I use to reproduce it?