npm spining in recvfrom() when run on s390x via qemu #50339
Comments
|
@nodejs/platform-s390 |
|
@hardillb have you tried this with the other non-Alpine containers? |
|
@hardillb I assume there must be some additional setup required in terms of installing QEMU etc. Can you provide the platform you were running on as well as the full set of steps for setup required before you run the docker line. Running on my x86 machine just gave me: |
|
The latest version of docker will use relative paths for volume mounts, but the older versions need a full path so the full instructions are:
(also changed the I get the same behaviour swapping out the I also get the same behaviour when running on a Fedora 38 or an Ubuntu based host OS (and on GitHub Actions which is where I originally saw this) |
|
Do the host and guest system differ in endianness? I'm guessing the answer is 'yes' because s390x is big endian and the host is presumably x86_64? You're quite possibly hitting qemu/qemu@44cf6731d6b and that's fixed in qemu 8. |
|
All the hosts have been AMD64 based so far. I'll try and work out how to get a copy of qemu 8 and docker to test. Assuming it is then the problem may be how to get this all deployed to GH Actions with the actions from Docker. |
|
But also this used to work, so given the fix is to do with IPv6 addresses, had npmjs.org rolled out IPv6 recently? I know that NodeJS changed it's default behaviour about which address it presents first if both IPv4 & IPv6 addresses are returned via DNS. I know there is the |
|
I've just tested with the following: Which should force the use of an IPv4 address and I get the same hang, so that looks like it may not be the mentioned qemu issue. |
|
@hardillb apologies for nosing into this issue, but, to check my understanding, I believe you're running this on an Initially, I read it that you were running this on an actual I say that because, for me, using Ubuntu
but instead returns: -
with: -
So, just to check, this is QEMU emulating |
|
@davidhay1969 yes, this is when using the |
|
Hi @hardillb OK, so I used the following setup: -
and setup multi-platform support via Multi-platform images
which returned: - {
"supported": [
"linux/amd64",
"linux/arm64",
"linux/riscv64",
"linux/ppc64le",
"linux/s390x",
"linux/386",
"linux/mips64le",
"linux/mips64",
"linux/arm/v7",
"linux/arm/v6"
],
"emulators": [
"python3.10",
"qemu-aarch64",
"qemu-arm",
"qemu-mips64",
"qemu-mips64el",
"qemu-ppc64le",
"qemu-riscv64",
"qemu-s390x"
]
}With that in place, I was able to start a container from the
and confirm the
I was then able to run the Node image as per your suggestion above : -
which, as per my experiment on a real and If I time the So it takes a wee while but doesn't hang If I prune Docker via
Apart from Multi-platform images I also reviewed Emulating a big-endian s390x with QEMU, especially given that I so rarely use Not sure whether this is of ANY use ? |
|
@hardillb were my ramblings of any small use ? |
|
It's still failing for all s390x builds running on GitHub Actions And when I run it locally, the only major difference is I'm on a 6.2.0-35 kernel |
|
@davidhay1969 just out of interest does your test machine have IPV6 access? |
|
Hey @hardillb just tested with a new
{
"supported": [
"linux/amd64",
"linux/arm64",
"linux/riscv64",
"linux/ppc64le",
"linux/s390x",
"linux/386",
"linux/mips64le",
"linux/mips64",
"linux/arm/v7",
"linux/arm/v6"
],
"emulators": [
"python3.10",
"qemu-aarch64",
"qemu-arm",
"qemu-mips64",
"qemu-mips64el",
"qemu-ppc64le",
"qemu-riscv64",
"qemu-s390x"
]
}
With regard to IPv6, as of now, the answer is "No", the VM doesn't have an v6 address, as evidenced by: -
I'll enable IPv6 and see what goes 💥 💥 |
|
Using a VSI on IBM Cloud now, rather than something running here in HURS: -
{
"supported": [
"linux/amd64",
"linux/arm64",
"linux/riscv64",
"linux/ppc64le",
"linux/s390x",
"linux/386",
"linux/mips64le",
"linux/mips64",
"linux/arm/v7",
"linux/arm/v6"
],
"emulators": [
"qemu-aarch64",
"qemu-arm",
"qemu-mips64",
"qemu-mips64el",
"qemu-ppc64le",
"qemu-riscv64",
"qemu-s390x"
]
}
So, with both IPv4 and IPv6, things seem to just work for me ? 🤔 🤔 🤔 🤔 |
|
I've been playing with this again (as it's still a problem). I've been using AWS EC2 machines to try out a few different options.
|
|
Hmmm, much weirdness here 😢 I just had another quick poke on an
and spun up a container using the
but just starting a shell instead of the
I can run
which does .... something: - with a complete log: -
So stuff appears to happen i.e. the proces never hangs for me, but I don't know etc. mean I also tried the
with the same effect: -
Not sure what I'm doing wrong ? 🤔 |
|
Picking up on the npm ERR! Tracker "idealTree" already exists while creating the Docker image for Node project so did the same as before: -
but then created/used a directory, within which I ran the
This took longer, with a nice progress bar e.g. but finally ( after ~3 mins ) completed with: - |
|
|
|
Not sure if any of this is of any use @hardillb 😢 |
|
OK, this is now failing with armv7 and NodeJS v20 for the new Node-RED 4.0 beta builds |
|
This may be related to https://gitlab.com/qemu-project/qemu/-/issues/2485. |
Version
v18.18.2
Platform
Linux c8fdac6bf542 6.4.15-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 7 00:25:01 UTC 2023 s390x Linux
Subsystem
No response
What steps will reproduce the bug?
How often does it reproduce? Is there a required condition?
Every time
What is the expected behavior? Why is that the expected behavior?
npm to complete run on emulated s390x as this is the standard way to build s390x containers when no access to s390x hardware.
What do you see instead?
Hang and 100% cpu from the npm process
Additional information
See nodejs/docker-node#1973 for qemu strace output
The text was updated successfully, but these errors were encountered: