Raspberry Pi 4, solid green LED

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!

1 Like

Yeah - it was one of those days :hot_face:
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.

Here’s an example of container healthchecks anyway: https://github.com/balena-io-playground/healthcheck-publicurl

@chrisys I don’t know enough about Docker/Node.js, but I would just think something could be done to protect against such a scenario.

The maintainer of node-rpio is really awesome, and I am sure he will answer in this issue. I looked through the code, and I think the problem might be related to this line: https://github.com/jperkin/node-rpio/blob/cc33c3fff98a0d4d3346788cc5bcb98bc7a4aca2/lib/rpio.js#L634

But let’s see :slight_smile:

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 :stuck_out_tongue:

1 Like