I am trying to get an Node.js v12 application running on Raspberry Pi 4 - but I am running into some problems. I have tested the code on my local machine, and seems to run fine.
When I first create the SD from the balena dashboard, everything works fine. I enable local mode and deploy my code with sudo balena push 192.168.8.127 -s . Initially this works fine, but then after some time it crashes. Can’t discover the Pi on the network. Red and green LED’s are constant ON. What I did to trouble shoot:
It’s an official Raspberry Pi 4 power supply
SD card is 32GB SanDisk 10 A1
Remove and add power does not help (when giving power to the Pi, the green LED flashes for 10 seconds, before going solid ON)
Inspecting the SD card on my Mac shows Resin boot, and everything seems ok
When I deploy a “clean” image, before pushing any code, the problem does not occur.
How to continue from here?
Update 1
I am currently trying to deploy the codebase to a Raspberry Pi 3 connected with Ethernet.
Update 2
After spending the day fixing this, I found the problem. Created an github issue here, with a description and solution.
Hi there, it seems you figured out the cause by yourself, great to hear! It does sound to me like some loop in the application completely blocks the device (thus the LEDs being constantly ON), and from what I can see in the issue you created it appears that debouncing the query for changes fixes the issue, which is expected as far as I can tell. If you have any other issues, let us know!
Yeah - it was one of those days
Just brain storming for future “beginner” Balena users. Would there be any way the Balena service could stop/halt the code in the container, if it completely blocks for let’s say 5 minutes? A warning, a log, just some hint (other than the green LED)?
@alexb the balena supervisor does have watchdog/healthcheck functionality but it sounds like the bug you’ve discovered is killing the device at a much lower level meaning the OS can’t do anything either. The base balenaOS would still need to be functional for the healthchecks to work. The fact that it wasn’t accessible even on LAN suggests the OS has halted.
Lets hope the maintainer has some insight there. Sadly is the gpio calls are some how halting the kernel, there isn’t much docker or node.js can do to protect against it because they would need a responsive kernel to get anything done