bullmq icon indicating copy to clipboard operation
bullmq copied to clipboard

[Bug]: multiple open msgpackr processes after terminating a node.js process that uses bullmq

Open HosseinAgha opened this issue 2 years ago • 10 comments

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.

Screenshot 2023-09-12 at 5 00 52 PM

All the node processes details are the same as above:
Screenshot 2023-09-12 at 5 04 46 PM

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

HosseinAgha avatar Sep 12 '23 13:09 HosseinAgha

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.

manast avatar Sep 12 '23 15:09 manast

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.

HosseinAgha avatar Sep 13 '23 06:09 HosseinAgha

What makes you believe msgpackr is creating this issue? BTW; it is just plain javascript: https://www.npmjs.com/package/msgpackr

manast avatar Sep 13 '23 06:09 manast

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.

HosseinAgha avatar Sep 13 '23 07:09 HosseinAgha

I see, it states that it is an optional dependency but it is enabled by default: https://www.npmjs.com/package/msgpackr

manast avatar Sep 13 '23 08:09 manast

Are you using sandboxed processors or standard?

manast avatar Sep 13 '23 08:09 manast

We are using the standard processors.

HosseinAgha avatar Sep 17 '23 11:09 HosseinAgha

In order to be able to investigate this issue further we would need some simple test that we can run to reproduce it.

manast avatar Sep 22 '23 13:09 manast

Actually, I don't know a good way to provide you with a MacOS sandbox. I can confirm this only happens in MacOS.

HosseinAgha avatar Sep 23 '23 10:09 HosseinAgha

@HosseinAgha I am on Mac. What piece of test code should I use to reproduce it?

manast avatar Sep 23 '23 13:09 manast