[email protected] fails in docker container on rpi

[avakarev]

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]

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

[Doridian]

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]

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

[juanhaywood]

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]

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

[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.

[WeeJeWel]

I am seeing the same issue.

[joshuawwright]

@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]

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

[joshuawwright]

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

[NickXML]

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]

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]

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]

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]

@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]

@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]

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]

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]

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]

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.

• package https://www.npmjs.com/package/@serialport/bindings-cpp
• release https://github.com/serialport/bindings-cpp/releases/tag/v11.0.0

[hardillb]

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]

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]

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

[reconbot]

[email protected] is released with these changes

[GazHank]

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

[hardillb]

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

[GazHank]

thanks @hardillb

[JeromeGillard]

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))