node-build-monitor
node-build-monitor copied to clipboard
Stops after a certain time of operation
Node build monitor stops after a certain time of operation. Here's what I have in the logs:
2:31:41 PM | 28 builds found....
2:32:11 PM | Check for builds...
2:32:12 PM | 28 builds found....
2:32:42 PM | Check for builds...
2:32:44 PM | 28 builds found....
warn: --minUptime not set. Defaulting to: 1000ms
warn: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
error: Could not read .foreverignore file.
error: ENOENT: no such file or directory, open '/build-mon/app/.foreverignore'
Printing environment Variables...
PORT = unset (Default: 3000)
NODE_TLS_REJECT_UNAUTHORIZED = 0
node-build-monitor is starting...
2:36:55 PM | Check for builds...
node-build-monitor 0.9.49 is listening on port 3000...
Node build monitor stops after a certain time of operation
Could you indicate after what time it stops and the frequency?
He stops randomly after a few days in general.
I've also no idea why this happens for some people. In the config above it looks like an issue of forever.
We had the same issue, but PR #146 should fix this. (There where some unhandled exceptions) At least, we have no problem since then. Have you tried also that release or above?
We are also seeing this. No error on the console or anywhere, it just stops. We are using the latest docker build.
Bump. Same behavior for us. After approximately two days of operation it stops working. We are currently on version-0.9.56.
11:21:53 AM | 37 builds found....
11:22:23 AM | Check for builds...
11:22:30 AM | 37 builds found....
11:23:00 AM | Check for builds...
11:23:08 AM | 37 builds found....
11:23:38 AM | Check for builds...
/build-mon/app/services/GitLab.js:46
pipelines = pipelines.filter(function(pipeline) {
^
TypeError: pipelines.filter is not a function
at /build-mon/app/services/GitLab.js:46:43
at Request._callback (/build-mon/app/services/GitLab.js:36:17)
at Request.self.callback (/build-mon/node_modules/request/request.js:185:22)
at emitTwo (events.js:106:13)
at Request.emit (events.js:194:7)
at Request.<anonymous> (/build-mon/node_modules/request/request.js:1161:10)
at emitOne (events.js:96:13)
at Request.emit (events.js:191:7)
at IncomingMessage.<anonymous> (/build-mon/node_modules/request/request.js:1083:12)
at Object.onceWrapper (events.js:293:19)
error: Forever detected script exited with code: 1
error: Script restart attempt #1
Printing environment Variables...
PORT = unset (Default: 3000)
NODE_TLS_REJECT_UNAUTHORIZED = unset (Default: 1)
node-build-monitor is starting...
11:24:24 AM | Check for builds...
node-build-monitor 0.9.56 is listening on port 3000...
Our current state ist that we have deactivated "forever", as we want that container do crash if the application has an issue. Now Kubernetes takes care of restarting the instance. All in all this makes the service provieded by node-build-monitor more stable. BUT without "forever" I have discovered that the application crashes due to an memory leak. See:

Has anyone seen the same behaviour?
Similar issue here
[36mcimonitor_1 | [0m 10:31:31 AM | 30 builds found....
[36mcimonitor_1 | [0m 10:32:01 AM | Check for builds...
[36mcimonitor_1 | [0m [33mwarn[39m: --minUptime not set. Defaulting to: 1000ms
[36mcimonitor_1 | [0m [33mwarn[39m: --spinSleepTime not set. Your script will exit if it does not stay up for at least 1000ms
[36mcimonitor_1 | [0m error: Could not read .foreverignore file.
[36mcimonitor_1 | [0m error: ENOENT: no such file or directory, open '/build-mon/app/.foreverignore'
[36mcimonitor_1 | [0m Printing environment Variables...
[36mcimonitor_1 | [0m PORT = unset (Default: 3000)
[36mcimonitor_1 | [0m NODE_TLS_REJECT_UNAUTHORIZED = unset (Default: 1)
[36mcimonitor_1 | [0m node-build-monitor is starting...
[36mcimonitor_1 | [0m 8:51:51 AM | Check for builds...
[36mcimonitor_1 | [0m node-build-monitor 0.9.56 is listening on port 3000...
[36mcimonitor_1 | [0m 8:52:01 AM | 33 builds found....
Same issue here, even if we restart the container every 6 hours, it still freezes almost every restart.