Skip to content
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

[email protected] fails in docker container on rpi #2438

Closed
avakarev opened this issue Feb 23, 2022 · 28 comments · Fixed by serialport/bindings-cpp#111
Closed

[email protected] fails in docker container on rpi #2438

avakarev opened this issue Feb 23, 2022 · 28 comments · Fixed by serialport/bindings-cpp#111

Comments

@avakarev
Copy link

SerialPort Version

10.3.0

Node Version

v14.19.0

Electron Version

No response

Platform

Linux raspberrypi 5.10.92-v7+ #1514 SMP Mon Jan 17 17:36:39 GMT 2022 armv7l GNU/Linux

Architecture

ARM

Hardware or chipset of serialport

QinHeng Electronics CH340

What steps will reproduce the bug?

I've created a repository at https://github.com/avakarev/serialport-docker-rpi to reproduce the issue.

Clone it and then:

make run-v9 # v9.2.8 on rpi

Using serialport ^9.2.8
serialport/stream opening path: /dev/ttyUSB0 +0ms
serialport/binding-abstract open +0ms
serialport/bindings/poller Creating poller +0ms
serialport/stream opened path: /dev/ttyUSB0 +10ms
port successfully opened

make docker-run-v9 # v9.2.8 on rpi in docker container

Using serialport ^9.2.8
2022-02-23T17:19:07.255Z serialport/stream opening path: /dev/ttyUSB0
2022-02-23T17:19:07.256Z serialport/binding-abstract open
2022-02-23T17:19:07.266Z serialport/bindings/poller Creating poller
2022-02-23T17:19:07.267Z serialport/stream opened path: /dev/ttyUSB0
port successfully opened

make run-v10 # v10.3.0 on rpi

Using serialport ^10.3.0
serialport/stream opening path: /dev/ttyUSB0 +0ms
serialport/bindings-cpp open +0ms
serialport/bindings-cpp/poller Creating poller +0ms
serialport/stream opened path: /dev/ttyUSB0 +11ms
port successfully opened

make docker-run-v10 # v10.3.0 on rpi in docker container

Using serialport ^10.3.0
2022-02-23T17:20:48.142Z serialport/stream opening path: /dev/ttyUSB0
2022-02-23T17:20:48.144Z serialport/bindings-cpp open
make[1]: *** [Makefile:8: _docker_run] Error 139

What happens?

serialport exits with 139 and have no stacktrace despite DEBUG=serialport*

What should have happened?

serialport should successfully open given port

Additional information

The alpine base image v12 used in demo repo is kinda outdated, but same behavior is met with alpine v14 and v15

Original discussion started at Koenkk/zigbee2mqtt#11545

@reconbot
Copy link
Member

reconbot commented Feb 26, 2022

So alpine (musl) on arm... probably a cross compilation issue, are you able to build from source?

@Doridian
Copy link

Doridian commented Mar 1, 2022

I should add this also happens on aarch64 alpine/musl.

Compiling the module myself and not using the prebuilts fixes the problem and makes everything work.

@svdbergh
Copy link

svdbergh commented Mar 4, 2022

Can you give a hint how to compile this on ARM?

@juanhaywood
Copy link

Maybe I'm misunderstanding the issue, but from what I'm reading it seems the compile went wonky? If so, could someone not just please recompile it?

@reconbot
Copy link
Member

reconbot commented Mar 8, 2022

We've had a release of bindings-cpp since this opened.

@hardillb
Copy link

Still seeing this with 10.3.0 and 10.7.0 bindings-cpp.

Running npm rebuild --build-from-source works, but the pre-built binaries crash.

@WeeJeWel
Copy link

WeeJeWel commented Jul 7, 2022

I am seeing the same issue.

@joshuawwright
Copy link

joshuawwright commented Jul 7, 2022

@hardillb

Still seeing this with 10.3.0 and 10.7.0 bindings-cpp.

Running npm rebuild --build-from-source works, but the pre-built binaries crash.

Did it run for you after rebuilding?

@hardillb
Copy link

hardillb commented Jul 7, 2022

@DesertFoxNV is that question really for me? The last line of the quote appears to answer what you are asking.

@joshuawwright
Copy link

@hardillb Sorry for the confusion. Ya, sorry it was. I was fighting yarn, but your solution worked thanks!

@NickXML
Copy link

NickXML commented Aug 24, 2022

There's definitely still an issue with Docker + Raspberry Pi and node-serialport.

As others have noted, if you use the 1.0.1 version of node-red-serialport, the Docker container gets stuck in a boot/crash loop. I inadvertently updated the version of node-red-serialport to the latest yesterday (I forgot about the bug) and was instantly back in reboot hell. The only solution that worked for me was to revert to the v0.15.0 of node-red-serialport.

The maintainers of node-red-serialport are convinced that the issue is in node-serialport. See .

Yes, you can rebuild the packages and sometimes it works (although it didn't seem to for me yesterday), or downgrade, but a fix to the pre-compiled binaries would really be helpful.

@mlooise
Copy link

mlooise commented Aug 27, 2022

I too can confirm that there is an issue with this version running on Docker + Raspberry Pi (Pi 3 in my case). It took me quite a while to find out why my flow in nodered would constantly crash the container when using node-red-serialport. Using trail & error found out that older version (< 0.15.0) of node-red-serialport still work but the newest (1.0.1) does not. Looking in the repo of node-red-serialport this relates to switching from "serialport" : "^9.2.5" to "serialport" : "^10.3.0". (this threads version). (copied from the commit)

In my case the use of the serialport 10.3.0 (also when writing a small test node script) resulted in a segmentation fault crashing node. When using in node-red it crashes the entire container resulting in a non-starting container (until changing the device mapping in the stack).

For now the workaround seems to be to manually go into the container and install [email protected]; then everything is ok and the flows work again in node-red. Just using latest (by using the palette) causes the problem/crash.

7 Segmentation fault (core dumped) /usr/local/bin/node $NODEOPTIONS node_modules/node-red/red.js --userDir /data $FLOW

If there is anything I can do to help; I can easily reproduce the problem on my environment using a default node-red stack on my Pi and then just use node & serialport in a small testscript.

update:
From what I can see the problem has been introduced between version 10.0.1 and version 10.1.0. Version 10.1.0 gives me the segmentation fault upon using the port:

const port = new SerialPort('/dev/ttyUSB1')
 
Segmentation fault (core dumped)

@hardillb
Copy link

As this is still broken, can I suggest you remove the broken binaries?

That would force them to be built on install which while adding to the install time does actually work, which has to be 100% better than shipping known broken binaries that will cause an application crash on first use?

@MichaelEFlip
Copy link

I discovered this problem on a raspberry pi 4 with node-red and node-red-node-serialport. This problem cost me a lot of time as node-red crashed without error. The error seems to originate from node-serialport and can be fixed by building the packages from source.
It would be good to fix the root cause of this problem. Thanks!

@yachal-upson
Copy link

@mlooise I want to extend a heartfelt thanks. Your post here (along with one other regarding npm package reversion) saved my project and my sanity. My dockerised Node-Red went into the aforementioned infinite boot loop after I made the mistake of updating the Serialport module. This after a whole afternoon trying to figure out what had hit me.
Couldn't even exec into the container for longer than a few seconds due to the looping.

I was able to get a stable platform to work with by adding the following entrypoint clause to my docker-compose.yml:

entrypoint: "npm start -- --userDir /data --safe"

From there I exec'd into the container. I also got back the web interface in safe mode. Can't remember but I think uninstallation of the offending module was blocked by it's use in my flows.

I located the module folder in the data directory (not the module folder in the install directory, as this is ephemeral). Manually deleted the module folder and re-installed the older version.

npm install [email protected]

Removed my docker-compose entrypoint clause and was back to a working instance.

@hardillb
Copy link

hardillb commented Nov 20, 2022

@reconbot Can we get an update on my request to remove the pre-built binaries as a work around to this problem, as it is shipping no binaries is 100% better than shipping broken binaries.

@Ekristoffe
Copy link

hello all, I too had a problem with this particular node on a different hardware. it took me a week to understand and see what was the problem.
Yes a npm rebuild --build-from-source solve the problem but it is not good to have a crash with precompiled binaries.
I was using a arm7, maybe we can try to see which binaries are good, which are bad and also find why some are bad (missing something, like a link, on the host ?).

@hardillb
Copy link

Can we please get the broken binaries remove, it really is the right (temporary) solution to this problem.

The bug has been open of over a year and there is a simple working solution available

@zcorey
Copy link

zcorey commented Apr 14, 2023

This issue still exists when using alpine:3.17.3 for Docker running on RPi4.

Adding the packages with apk add (python3 py3-pip make gcc g++ linux-headers udev) allows the rebuild process to complete successfully for node-red-node-serialport 1.0.3 however, still crashes the Docker container when connecting to the device.

It would be great to know if there is an actionable effort to have this problem fixed.

Thanks

reconbot added a commit to serialport/bindings-cpp that referenced this issue Apr 20, 2023
Two problems to fix with this one
- our rpi arm64 isn't working possibly because our libc is too new, so we'll target the lts of arm64, worked for [level](Level/classic-level#71) thankful for [their investigation](Level/classic-level#69)
- our arm64 builds were just broken and wouldn't build so we're fixing that with a variable in our binding.gyp for `openssl_fips`

When this is released it will hopefully fix serialport/node-serialport#2438
@reconbot reconbot reopened this Apr 20, 2023
@reconbot
Copy link
Member

I've released @serialport/[email protected] which should fix this issue. See serialport/bindings-cpp#111 for details. Binaries are packaged in the npm package so they can't easily be pulled. If this new release fixes your issue I'll cut a serialport release. It drops node 12 support so I want to wait to get the bindings right before upgrading.

@hardillb
Copy link

OK, so how do we test this?

The path to the failure is to install serialport in a alpine container, which has a fixed dependency on @serialport/bindings-cpp 10.8.0, it sounds like we need a beta release of serialport with the bindings-cpp version bumped to point to 11.0.0?

@reconbot
Copy link
Member

reconbot commented Apr 20, 2023

You can use @serialport/stream and pass in the bindings. Or just try to install and use the bindings directly. We don't have a way to a beta release right now.

@reconbot
Copy link
Member

I'm unable to purchase a raspberry pi as they are hard to find. So I can't verify anything myself unfortunately.

@reconbot
Copy link
Member

[email protected] is released with these changes

@GazHank
Copy link
Contributor

GazHank commented Jun 6, 2023

Hi @hardillb did you manage to update to V11 and confirm if this fixed the issue for you?

@hardillb
Copy link

hardillb commented Jun 6, 2023

@GazHank node-red-node-serialport has been updated with serialport v11 which appear to work

@GazHank
Copy link
Contributor

GazHank commented Jun 7, 2023

thanks @hardillb

@JeromeGillard
Copy link

I've managed to make [email protected] work on RaspberryPi after rebuilding the bindings-cpp:

In /data/node_modules/@serialport/bindings-cpp run npm run rebuild

(thanks to node-red/node-red-nodes#1027 (comment))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.