Почему висит" docker attach"?

я могу запустить ubuntu контейнер успешно:

# docker run -it -d ubuntu
3aef6e642327ce7d19c7381eb145f3ad10291f1f2393af16a6327ee78d7c60bb
# docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
3aef6e642327        ubuntu              "/bin/bash"         3 seconds ago       Up 2 seconds                            condescending_sammet

но-исполнителей docker attach зависает:

# docker attach 3aef6e642327

пока я не нажму любую клавишу, например Enter:

# docker attach 3aef6e642327
root@3aef6e642327:/#
root@3aef6e642327:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

почему docker attach вешать?

обновление:

после прочтения комментариев, я думаю, что я получаю ответы:

обязательное условие:

" docker attach " повторно использовать тот же tty, а не открывать новый tty.

(1) Выполнение docker run без режиме демона:

# docker run -it ubuntu
root@eb3c9d86d7a2:/# 

все в порядке, затем запустите :

root@eb3c9d86d7a2:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@eb3c9d86d7a2:/#

(2) Run docker run в режиме демона:

# docker run -it -d ubuntu
91262536f7c9a3060641448120bda7af5ca812b0beb8f3c9fe72811a61db07fc

на самом деле из работающего контейнера в stdout должно было быть выведено следующее:

root@91262536f7c9:/#

поэтому выполнение docker attach кажется, висит, но на самом деле он ждет вашего ввода:

# docker attach 91262536f7c9
ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@91262536f7c9:/#

6 ответов


это не зависание. Как вы можете видеть в комментарии ниже (вы работаете"/bin/bash " как команда), кажется, ожидаемое поведение при подключении.

насколько я понимаю, вы подключаетесь к запущенной оболочке и просто stdin/stdout/stderr - в зависимости от параметров, которые вы передаете вместе с командой run - просто покажет вам все, что входит / выходит С этого момента. (Кто-то с немного более глубокими знаниями к счастью, могу объяснить это на более высоком уровне).

как я написал в своем комментарии к вашему вопросу, есть несколько человек, которые открыли проблему на Docker GitHub repo, описывая подобное поведение:

так как вы упомянули Шелл, я предполагаю, что у тебя уже есть оболочка. attach не запускает новый процесс, так каково ожидаемое поведение подключения к потокам in/out/err запущенного процесса? Я не думал об этом. Конечно, это ожидаемое поведение присоединения к запущенной оболочке, но желательно ли это?

можно ли вообще сбросить stdout / stderr на Docker attach, тем самым заставляя запрос оболочки печататься или это немного сложнее? Это то, что я лично "ожидал" при подключении к уже запущенной оболочке.

не стесняйтесь закрывать этот вопрос, если это необходимо, я просто почувствовал необходимость документировать это и получить некоторую обратную связь.

если вместо enter вы начнете вводить команду, вы не увидите дополнительно пустая строка приглашения. Если бы ты побежал

$ docker exec -it ubuntu <container-ID-or-name> bash 

здесь <container-ID-or-name> - это идентификатор или имя контейнера после запуска docker run -it -d ubuntu (так 3aef6e642327 или снисходительно_sammet в вашем вопросе) он будет запускать новая команда, таким образом, не имея этой "проблемы stdout" присоединения к существующей.

пример

если бы Dockerfile в директорию, содержащую:

FROM ubuntu:latest
ADD ./script.sh /timescript.sh 
RUN chmod +x /timescript.sh
CMD ["/timescript.sh"]

и иметь простой Баш скрипт script.sh в том же каталоге, содержащем:

#!/bin/bash

#trap ctrl-c and exit, couldn't get out
#of the docker container once attached
trap ctrl_c INT
function ctrl_c() {
    exit
}

while true; do
    time=$(date +%N)
    echo $time;
    sleep  1;
done

затем построить (в этом примере в том же каталоге, что и Dockerfile и script.sh) и запустить его с

$ docker build -t nan-xiao/time-test .
..stuff happening...
$ docker run -itd --name time-test nan-xiao/time-test

наконец-то attach

$ docker attach time-test

вы в конечном итоге прикреплены к контейнеру, распечатывающему время каждую секунду. (CTRL-C, чтобы выйти)

Пример 2

или если у вас будет Dockerfile содержащий, например, следующий:

FROM ubuntu:latest
RUN apt-get -y install irssi
ENTRYPOINT ["irssi"]

затем запустите в том же каталоге:

$ docker build -t nan-xiao/irssi-test .

затем запустить его:

$ docker run -itd --name irssi-test nan-xiao/irssi-test

и наконец

$ docker attach irssi-test

вы бы в конечном итоге в работающей irssi окно без этого конкретного поведения. Конечно, вы можете заменить irrsi для другой программы.


я столкнулся с этой проблемой, а также при попытке прикрепить к контейнеру, который был разработан кем-то другим и уже запущен демон. (В этом случае это был LinuxServer transmission изображение docker).

:

случилось так, что терминал, казалось, "зависал", где ввод чего-либо не помогал и не появлялся. Только Ctrl-C вышвырнул бы меня обратно.

docker run, docker start, docker attach все не удалось, получается команда I необходимости (после того как контейнер был запущен с run или start) должен был выполнить bash, по мере того как шансы контейнера вытащил из не уже работает Баш.

устранение:

docker exec -it <container-id> bash

(вы можете найти container-id запуск docker ps -a).

это потянет вас в экземпляр с функциональным bash как root (при отсутствии других явных настройки сделать образ вытащил).

I знаю, что принятый ответ захватил это, но решил опубликовать еще один, который немного более лаконичен и очевиден, так как решение не выскочило для меня, когда я его читал.


Это случилось со мной однажды по следующей причине:

возможно, что команда bash внутри контейнера выполняет команду "cat".

поэтому, когда вы присоединяетесь к контейнеру (команда bash), вы фактически находитесь внутри команды cat, которая ожидает ввода. (текст и / или ctrl-d для записи файла)


Если вы не можете получить доступ к командной строке, просто убедитесь, что вы запустите контейнер с -i флаг на старте.


у меня сегодня была аналогичная проблема, и я смог ее исправить:

вот что происходило со мной:

docker-compose logs -f nginx
Attaching to laradock_nginx_1

тогда он будет висеть там, пока я не выйду через CTRL-C: ^CERROR: Aborting.

docker ps -a показал, что то, что должно было называться laradock_nginx не существовало с этим именем изображения, поэтому я решил, что просто удалю и повторно "подниму" этот контейнер:

docker stop cce0c32f7556
docker rm cce0c32f7556
docker-compose up -d laradock_nginx

к сожалению: ERROR: No such service: laradock_nginx

Итак, я сделал sudo reboot а то docker ps -a, но laradock_nginx еще не было.

к счастью, и работал docker-compose logs -f nginx теперь работает.


когда я запускаю docker attach container-name, затем ничего не выводить, даже Ctrl-c является недействительным. Итак, первая попытка

docker attach container-name --sig-proxy=false

а то ctrl-c может его остановить. Почему он ничего не выдал? только потому, что контейнер не выводится. На самом деле мне нужно ввести мой контейнер и запустить некоторую команду оболочки. Поэтому правильная команда

docker exec -ti container-name bash