deno icon indicating copy to clipboard operation
deno copied to clipboard

v1.29.3 panic in Docker: "OS can't spawn worker thread: Operation not permitted"

Open danopia opened this issue 2 years ago • 1 comments

Hi, my Dependabot found a rust panic when updating a project from denoland/deno:alpine-1.29.2 to denoland/deno:alpine-1.29.3.

The issue happened when running a deno command on CircleCI's remote docker with Docker Engine version 20.10.7. It happens every time (tried 3 runs). I successfully worked around the panic by updating Docker Engine to 20.10.18. I'm not sure what reproducability is like elsewhere, though I imagine having the correct docker engine version would be step one.

I'm reporting this because it's a panic and panics are bugs :) but updating docker is a reasonable workaround for many, I'd hope.

Step 5/5 : RUN deno cache *.ts
 ---> Running in 4636805d6740
Download https://deno.land/x/[email protected]/mod.ts

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: linux x86_64
Version: 1.29.3
Args: ["deno", "cache", "cloudflare.ts", "dockerhub.ts", "mongodb-atlas.ts"]

thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.20/src/client/connect/dns.rs:121:24
stack backtrace:
   0: rust_begin_unwind
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/69f9c33d71c871fc16ac445211281c6e7a340943/library/core/src/panicking.rs:65:14
   2: <hyper::client::connect::dns::GaiResolver as tower_service::Service<hyper::client::connect::dns::Name>>::call
   3: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   4: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
   5: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   6: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   7: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   8: <futures_util::future::try_future::try_flatten::TryFlatten<Fut,<Fut as futures_core::future::TryFuture>::Ok> as core::future::future::Future>::poll
   9: <futures_util::future::either::Either<A,B> as core::future::future::Future>::poll
  10: <hyper::common::lazy::Lazy<F,R> as core::future::future::Future>::poll
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  12: <reqwest::async_impl::client::PendingRequest as core::future::future::Future>::poll
  13: <reqwest::async_impl::client::Pending as core::future::future::Future>::poll
  14: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  15: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  17: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  18: <futures_util::future::future::Map<Fut,F> as core::future::future::Future>::poll
  19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  21: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  22: deno::run_subcommand::{{closure}}
  23: deno::main::{{closure}}
  24: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  25: deno_runtime::tokio_util::run_local
  26: deno::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
The command '/bin/sh -c deno cache *.ts' returned a non-zero code: 1

For what it's worth, this is my Dockerfile, it's quite simple:

FROM denoland/deno:alpine-1.29.3

COPY src /src
WORKDIR /src

# download all dependencies & check types
RUN deno cache *.ts

danopia avatar Jan 16 '23 14:01 danopia

+1 on this

docker run -it denoland/deno:alpine-1.30.2


#
# Fatal error in , line 0
# Check failed: Start().
#
#
#
#FailureMessage Object: 0x7ffffe4bad00%

Hexagon avatar Feb 05 '23 21:02 Hexagon

Alpine still doesn't work with 1.30.3, same error. My issue seem related to initial post as it started at 1.29.3.

Hexagon avatar Feb 12 '23 10:02 Hexagon

My issue seem related to initial post as it started at 1.29.3.

Have you tried updating your Docker engine? Or are you running Alpine Linux directly on a machine?

danopia avatar Feb 13 '23 08:02 danopia

Anyone found a solution to this yet? Linting with version 1.35.3 has the same error My docker file is starting from denoland/deno:alpine-1.35.3 someting like

FROM denoland/deno:alpine-1.35.3 as api

# other commands

RUN deno lint .

# other commands

Am assuming its related so i didn't open a new issue. The deno lint command fails with

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.
Platform: linux x86_64
Version: 1.35.3
Args: ["deno", "lint", "."]
thread 'main' panicked at 'OS can't spawn worker thread: Operation not permitted (os error 1)', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/deno_core-0.[197](https://gitlab.com/sigma-ratings/monorepo/-/jobs/4778371762#L197).0/task.rs:71:16
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

RrNn avatar Aug 01 '23 11:08 RrNn

For me, the solution was updating my Docker engine. Deno stopped encountering the panic after Docker was upgraded. If possible, I'd recommend checking and updating your Docker engine as well

danopia avatar Aug 01 '23 14:08 danopia

Closing this issue -- it appears that older versions of docker are causing the crash.

For those encountering this error in the future, this is likely because your version of docker is too old:

OS can't spawn worker thread: Operation not permitted (os error 1)

mmastrac avatar Apr 04 '24 23:04 mmastrac