-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
setInterval stops working after the service has been running for some time (so far 4-10 days). #41037
Comments
@nodejs/timers |
I'm experiencing the same problem. It stops when it's almost two months using timeout and promise. There is no error. current node version is 16.13.0. |
For what it's worth I tried running a code similar to the OP for a few days (though with a different OS) and was unable to reproduce. If there is a repo I can clone and run for a few days to reproduce with all the debug logs active and strace that would be useful. |
The timers code, other than usage of libuv, has been almost entirely rewritten since 2017 so if this is indeed the case, it seems like either C++ or libuv layer bug. I'll try to investigate but the fact that we haven't been able to get a barebones, reliable reproduction from anyone, makes this really hard. |
@bnoordhuis would probably be the best person to know if it was a libuv bug: https://github.com/libuv/libuv/commits/v1.x/src/timer.c |
The problem is that this is a private company repo so I can't share the code, as for the duration, like I said it's arbitrary, on some servers it happens after a few days, others after a few weeks, and others don't have the issue at all. I absolutely understand how hard this would be to debug, I just wanted to point it out, and maybe understand what is causing it, as for the time being, I already re-wrote the code using node-cron, and I haven't ran into the issue yet, but will need to see how it performs long term. either way, thanks everyone for the help! |
@kerus1024 what operating system and architecture ( |
it is running on 4.19.0-18-amd64 (general cloud providers linux vm instance) when it throws an error, it is not work for next loop in await loop around once in 40 days. |
My hunch was an aarch64 kernel bug (libuv already works around several) but no such issues exist on x86_64, to my knowledge. |
This issue has been open for a while with no movement, node v12.x has been out of support for some time, and it's not even clear whether it's a bug in node or some other component, so I'm going to close it. |
Same issue happening to me on Node v19.2.0. Will try to use a stable v18.16.0 and see if the issue persists. I described the issue more here: Node.js - setTimeout is sometimes not being fired |
Version
v12.18.1
Platform
Linux DEV-PH-CVR-02 4.9.140-tegra #1 SMP PREEMPT Sat Oct 19 15:54:06 PDT 2019 aarch64 aarch64 aarch64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
I am running this function inside of a service, the socket here is a tls-socket, after this service keeps running for an arbitrary number of days, the callback provided to setInterval stops getting executed, I am quite confident this is an issue with setInterval as the rest of the process keeps functioning as expected, I tried looking for some possible resource leakage, unhandled errors, etc.. in the service, but couldn't find any.
How often does it reproduce? Is there a required condition?
seems to happen every time the process has been running for a while, but didn't have the opportunity to figure out how long after it's been running exactly does this happen.
What is the expected behavior?
setInterval keeps running as normal.
What do you see instead?
setInterval stops executing its callback.
Additional information
I am not 100% sure this is an issue with setInterval, but I couldn't find any other possible reason for the bug, and saw some people mentioning the same issue here: #22149 (have to scroll down).
If this is already solved, it would be great if a way to replicate this issue could be provided, thanks!
The text was updated successfully, but these errors were encountered: