deno: Deno hangs in Ubuntu

I’ve been trying to run Deno on an Ubuntu server but I’m finding that it hangs on reading the file it’s running. I initially was trying to run this on the maxmcd/deno docker image. I then tried installing/running Deno on the machine itself and ran into the same issue.

I’m a little out of my depth to debug this so any guidance would be appreciated.

Ubuntu version 18.04.2 LTS (Bionic Beaver)

> echo 'console.log("foo")' > foo.ts
> ./.deno/bin/deno --version
deno: 0.3.7
v8: 7.4.238
typescript: 3.4.1
> ./.deno/bin/deno -AD foo.ts
DEBUG RS - mkdir -p /home/piet/.cache/deno/gen
DEBUG RS - set dir perm to 493
DEBUG RS - mkdir -p /home/piet/.cache/deno/deps
DEBUG RS - set dir perm to 493
DEBUG RS - mkdir -p /home/piet/.cache/deno/deps/http
DEBUG RS - set dir perm to 493
DEBUG RS - mkdir -p /home/piet/.cache/deno/deps/https
DEBUG RS - set dir perm to 493
DEBUG RS - root /home/piet/.cache/deno
DEBUG RS - gen /home/piet/.cache/deno/gen
DEBUG RS - deps /home/piet/.cache/deno/deps
DEBUG RS - deps_http /home/piet/.cache/deno/deps/http
DEBUG RS - deps_https /home/piet/.cache/deno/deps/https
DEBUG RS - Deno isolate init with snapshots.
DEBUG RS - resolve_module specifier foo.ts referrer .
DEBUG RS - msg_from_js Start sync true
DEBUG JS - cwd /home/piet
DEBUG JS - args [ "foo.ts" ]
DEBUG RS - resolve_module specifier foo.ts referrer .
DEBUG RS - main_module file:///home/piet/foo.ts
DEBUG RS - fetch_module_meta_data. specifier file:///home/piet/foo.ts referrer .
DEBUG RS - resolve_module specifier file:///home/piet/foo.ts referrer .
DEBUG RS - module_name: file:///home/piet/foo.ts, filename: /home/piet/foo.ts
DEBUG RS - fetch local or reload file:///home/piet/foo.ts is_module_remote false
DEBUG RS - found local source

Then it hangs indefinitely.

Let me know what other info I can provide.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 17 (11 by maintainers)

Most upvoted comments

I just tested this bug with #2380 landed, even if there’s only 1 core available Deno no longer hangs.

@ry I think we can close this issue now

bartlomieju on May 29, 2019

@afinch7 thanks for the ping, happy to help!

There are 2 scenarios where this can happen (in my experience):

Only 1 cpu core available on the system (like in a VM with 1 vCPU.) Deno needs more than 1 thread to compile code.
Not enough entropy generated on the system (this was harder to figure out.) Check cat /proc/sys/kernel/random/entropy_avail (also our dmesg should show something like crng init done if it has enough entropy)

Low entropy prevents things like TLS handshakes which deno relies on to fetch resources. You can make entropy higher by interacting with the system normally for a while (but it might be a long process) or by adding entropy to the system via RNDADDENTROPY. You can generate bad entropy with this golang script: https://gist.github.com/jeromegn/ba3f694412979d21dafc9d625b8fcf04 or this python 3 script: https://github.com/linuxkit/linuxkit/issues/3096#issuecomment-403301359 or by using something like haveged or rngd programs. You can also seed entropy from the last boot or the host (if you’re running a VM.)

Hope this helps!

jeromegn on Apr 16, 2019

There’s a chance tokio’s threadpool spawns a single worker since it only detects 1 logical core. Then you run blocking operations on it (like fs-related stuff, which is allowed since it’s not considered a single-threaded tokio runtime) and that just blocks everything in the event loop.

AFAICT deno_dir wraps async methods in blocking() calls and uses sync approach, there is even TODO to change this behavior not to block. I can take a look at it in the evening.

bartlomieju on May 7, 2019

I don’t understand either. Deno does use a separate thread to compile typescript but surely having 1 CPU wouldn’t prevent that from happening…

ry on Apr 16, 2019