docker-registry-browser: ExecJS can't find a runtime

Possibly not related to this specific image, but ExecJS can’t find a runtime when we try to run this image as non-root:

https://github.com/klausmeyer/docker-registry-browser/issues/434

User is configured:

~ $ whoami
app

Binary is set (forked the image, and changed the perms on this binary, but not necessary for execution per se):

~ $ ls -all /usr/bin/node 
-rwxr-xr-x    1 app      app       36962824 Oct 13 10:24 /usr/bin/node

It is also linked in PATH:

~ $ which node
/usr/bin/node

And works fine:

~ $ node -e 'console.log(42)'
42

However:

~ $ puma -C config/puma.rb 
Puma starting in single mode...
* Puma version: 5.5.2 (ruby 2.6.8-p205) ("Zawgyi")
*  Min threads: 5
*  Max threads: 5
*  Environment: production
*          PID: 26
! Unable to load application: ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes.
/usr/local/bundle/gems/execjs-2.8.1/lib/execjs/runtimes.rb:58:in `autodetect': Could not find a JavaScript runtime. See https://github.com/rails/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
	from /usr/local/bundle/gems/execjs-2.8.1/lib/execjs.rb:5:in `<module:ExecJS>'
	from /usr/local/bundle/gems/execjs-2.8.1/lib/execjs.rb:4:in `<main>'
	from /usr/local/bundle/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `require'
	from /usr/local/bundle/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:23:in `block in require_with_bootsnap_lfi'
	from /usr/local/bundle/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/loaded_features_index.rb:92:in `register'
	from /usr/local/bundle/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:22:in `require_with_bootsnap_lfi'
	from /usr/local/bundle/gems/bootsnap-1.9.1/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:31:in `require'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler/runtime.rb:66:in `block (2 levels) in require'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler/runtime.rb:61:in `each'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler/runtime.rb:61:in `block in require'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler/runtime.rb:50:in `each'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler/runtime.rb:50:in `require'
	from /usr/local/bundle/gems/bundler-2.2.22/lib/bundler.rb:174:in `require'
	from /app/config/application.rb:16:in `<top (required)>'
	from /app/config/environment.rb:2:in `require_relative'
	from /app/config/environment.rb:2:in `<top (required)>'
	from config.ru:3:in `require_relative'
	from config.ru:3:in `block in <main>'
	from /usr/local/bundle/gems/rack-2.2.3/lib/rack/builder.rb:116:in `eval'
	from /usr/local/bundle/gems/rack-2.2.3/lib/rack/builder.rb:116:in `new_from_string'
	from /usr/local/bundle/gems/rack-2.2.3/lib/rack/builder.rb:105:in `load_file'
	from /usr/local/bundle/gems/rack-2.2.3/lib/rack/builder.rb:66:in `parse_file'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/configuration.rb:345:in `load_rackup'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/configuration.rb:267:in `app'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/runner.rb:149:in `load_and_bind'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/single.rb:44:in `run'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/launcher.rb:181:in `run'
	from /usr/local/bundle/gems/puma-5.5.2/lib/puma/cli.rb:80:in `run'
	from /usr/local/bundle/gems/puma-5.5.2/bin/puma:10:in `<top (required)>'
	from /usr/local/bundle/bin/puma:23:in `load'
	from /usr/local/bundle/bin/puma:23:in `<main>'

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 23 (7 by maintainers)

Most upvoted comments

“sudo apt-get upgrade” to SMP Debian 4.19.235-1 worked for me

sfewings on May 18, 2022

Usually there should be files in public/assets/.... They’re generated by the rails assets:precompile in the Dockerfile.

But coming back to the actual issue with the File.executable?. I’ve now read a bit in the issues you linked above and I remember that I came across similar issues before. It has something to do with the underlaying syscalls and their mapping:

Alpine 3.14 seems to have known problems when running on a host with older libseccomp. Do you by any chance have access on the docker host and can check what version is installed there?

klausmeyer on Nov 1, 2021

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. In theory it’s only needed to precompile the assets during the image-build. In the run it might be even obsolete.

klausmeyer on Nov 1, 2021