Сбой контейнера при запуске с помощью команды RUN, но работает из оболочки bash

Question

Я пытаюсь создать контейнер для команды 'navi', но когда я пытаюсь запустить контейнер с помощью команд Dockerfile ENTRYPOINT или CMD, происходит сбой. Если я запускаю контейнер с оболочкой bash (т.е. CMD ["bash"]), то запускаю команду 'navi', она работает нормально.

Пожалуйста, дайте мне знать, что я делаю неправильно, или если зависимости просто не поддерживают запуск из контейнера.

FROM rust

RUN apt-get -y update \
    && apt-get -y install \
        fzf \
    && cargo install navi \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

ENV TERM=xterm-256color

ENTRYPOINT ["navi"]

Это команды, которые я использую для его сборки и запуска

docker build -t macabees/navi:latest navi/.
docker run -it --rm --name navi macabees/navi 

Вот ошибка, которую я получаю:

panic: runtime error: index out of range
goroutine 40 [running]:
github.com/junegunn/fzf/src.(*Terminal).printItem(0xc000106000, 0xc000155838, 0x0, 0x3, 0x1, 0x53fd00)
github.com/junegunn/fzf/src/terminal.go:827 +0x6b5
github.com/junegunn/fzf/src.(*Terminal).printList(0xc000106000)
github.com/junegunn/fzf/src/terminal.go:802 +0x254
github.com/junegunn/fzf/src.(*Terminal).Loop.func8.1(0xc00000cd60)
github.com/junegunn/fzf/src/terminal.go:1551 +0x1de
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc00000cd60, 0xc0001acf98)
github.com/junegunn/fzf/src/util/eventbox.go:34 +0x5e
github.com/junegunn/fzf/src.(*Terminal).Loop.func8(0xc000106000, 0xc0001b00a0)
github.com/junegunn/fzf/src/terminal.go:1538 +0x97
created by github.com/junegunn/fzf/src.(*Terminal).Loop
github.com/junegunn/fzf/src/terminal.go:1534 +0x36f
thread 'main' panicked at 'External command failed:
', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/navi-2.2.0/src/fzf.rs:127:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Вывод обратной трассировки

panic: runtime error: index out of range goroutine 26 [running]:
github.com/junegunn/fzf/src.(*Terminal).printItem(0xc000116000, 0xc000155838, 0x0, 0x3, 0x1, 0xffffffffffffff00) github.com/junegunn/fzf/src/terminal.go:827 +0x6b5                                                                  github.com/junegunn/fzf/src.(*Terminal).printList(0xc000116000)                                                    github.com/junegunn/fzf/src/terminal.go:802 +0x254 github.com/junegunn/fzf/src.(*Terminal).Loop.func8.1(0xc00000cd60)
github.com/junegunn/fzf/src/terminal.go:1551 +0x1de
github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc00000cd60, 0xc00003b798)                                                       github.com/junegunn/fzf/src/util/eventbox.go:34 +0x5e
github.com/junegunn/fzf/src.(*Terminal).Loop.func8(0xc000116000, 0xc0001940c0)
github.com/junegunn/fzf/src/terminal.go:1538 +0x97 created by github.com/junegunn/fzf/src.(*Terminal).Loop                          github.com/junegunn/fzf/src/terminal.go:1534 +0x36f thread 'main' panicked at 'External command failed:', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/navi-2.2.0/src/fzf.rs:127:13 stack backtrace:
0: backtrace::backtrace::libunwind::trace at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/libunwind.rs:88
1: backtrace::backtrace::trace_unsynchronized at ./cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.40/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt at src/libstd/sys_common/backtrace.rs:77
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write at src/libcore/fmt/mod.rs:1052
5: std::io::Write::write_fmt at src/libstd/io/mod.rs:1426
6: std::sys_common::backtrace::_print at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}} at src/libstd/panicking.rs:204
9: std::panicking::default_hook at src/libstd/panicking.rs:224
10: std::panicking::rust_panic_with_hook at src/libstd/panicking.rs:472
11: rust_begin_unwind at src/libstd/panicking.rs:380
12: std::panicking::begin_panic_fmt at src/libstd/panicking.rs:334
13: navi::fzf::call
14: navi::flows::core::main
15: navi::handler::handle_config
16: navi::main
17: std::rt::lang_start::{{closure}}
18: std::rt::lang_start_internal::{{closure}} at src/libstd/rt.rs:52
19: std::panicking::try::do_call at src/libstd/panicking.rs:305
20: __rust_maybe_catch_panic at src/libpanic_unwind/lib.rs:86
21: std::panicking::try at src/libstd/panicking.rs:281
22: std::panic::catch_unwind at src/libstd/panic.rs:394
23: std::rt::lang_start_internal at src/libstd/rt.rs:51
24: main
25: __libc_start_main
26: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Answer 1

Я не очень знаком с тем, как внутренне пишется navi, но я обнаружил, что при повторном запуске команды docker run -it --rm --name navi macabees/navi она будет работать примерно в 20% случаев.

Теперь вот некоторые изменения в этой команде, которые будут работать 100% времени:

docker run -it --rm \
  --name navi \
  --entrypoint bash \
  macabees/navi \
  -c "sleep 1; navi"

Я предполагаю, что для правильной работы команды navi необходимо сначала запустить или инициализировать некоторые процессы, если мы подождем некоторое время (1 с или более), эти процессы завершатся sh до того, как будет выполнена основная команда navi.

Чтобы улучшить ваш Dockerfile, вы можете создать сценарий оболочки как точка входа, которая будет ждать 1 с перед запуском navi.