ExecJS can't find a runtime #447
Comments
|
This also happens in the repository's version of Ruby, but tried a downgrade bc of issues at the execjs front: |
|
It does seem to be related to the issue that's attached to |
|
This might even be related to alpine: |
|
Doesn't seem to be a kernel / alpine issue: |
|
Considering the OS seems to be doing fine on this end, possibly going to monkeypatch this for the time being |
|
Thanks for looking into this topic and providing all the details 🙇🏻♂️ This confirms that the issue is somehow related to a combination of the used base-image and other influences from the docker-host itself. Wish I would be able to reproduce it myself somehow. But what I would like to check anyways is if I can get rid of the need of a JS runtime in general. |
|
Just manually patched the gem so that it returns |
|
Begs the question if possibly something went wrong during build-time, that would explain why Ruby tries to run node? |
Hm ... just to understand better - how exactly did you patch the gem?
Currently looking into it :-) |
Patched it in a very ugly way 😛 |
|
Not acquainted with ruby at all, so there's probably a way better solution to do this actually 😅 In a small script you can easily patch it using But considering a gem is running it, not sure how that hooks into the application |
|
Doesn't need to be perfect code to just see if it fixes the problem 😁 |
|
Ah, cool! Yeah, I edited the file ( |
|
|
Let me bump the container image to ruby version 3 again, possibly it's not working properly because of the downgrade (unfortunately can't make the container public) |
|
Ok I was talking about Anyways I've figured out in the meanwhile that I can't really get rid of the need of a JS runtime as one of the gems I'm using will always require it as one of it's downstream dependencies - even in the run 😞 |
|
Ah, interestingly - the files that it 404s on are in the |
|
Usually there should be files in But coming back to the actual issue with the Alpine 3.14 seems to have known problems when running on a host with older |
|
Yeah, let me check - I did try to rule that out by doing an -x check through busybox, but it seems that you're right indeed. |
|
I'm running the app myself on a system with the following specs: Note: I also had to update the |
|
TL;DR for other users running into this issue - update your containerd! If you can't, then override the check from execjs, personally I used this patch for it: --- external_runtime.rb
+++ external_runtime.rb
@@ -129,12 +129,18 @@
end
commands.find { |cmd|
+ if cmd == '/usr/bin/node'
+ return true
+ end
if File.executable? cmd
cmd
else
path = ENV['PATH'].split(File::PATH_SEPARATOR).find { |p|
full_path = File.join(p, cmd)
File.executable?(full_path) && File.file?(full_path)
+ if full_path == '/usr/bin/node'
+ return true
+ end
}
path && File.expand_path(cmd, path)
endAnd added this to the Dockerfile: RUN patch /usr/local/bundle/gems/execjs-2.8.1/lib/execjs/external_runtime.rb < patches/force-node-execjs.patch |
|
Some additional notes: I was able to reproduce it now by forcing the installation of older versions on a Debian 10 VM: |
|
"sudo apt-get upgrade" to SMP Debian 4.19.235-1 worked for me |
Possibly not related to this specific image, but ExecJS can't find a runtime when we try to run this image as non-root:
User is configured:
Binary is set (forked the image, and changed the perms on this binary, but not necessary for execution per se):
It is also linked in PATH:
And works fine:
However:
The text was updated successfully, but these errors were encountered: