Почему висит" 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, описывая подобное поведение:
- docker attach [контейнер] зависает, требует ввода #8521
- docker attach зависает, устанавливая состояние терминала при подключении к контейнеру
так как вы упомянули Шелл, я предполагаю, что у тебя уже есть оболочка. attach не запускает новый процесс, так каково ожидаемое поведение подключения к потокам in/out/err запущенного процесса? Я не думал об этом. Конечно, это ожидаемое поведение присоединения к запущенной оболочке, но желательно ли это?
можно ли вообще сбросить stdout / stderr на Docker attach, тем самым заставляя запрос оболочки печататься или это немного сложнее? Это то, что я лично "ожидал" при подключении к уже запущенной оболочке.
не стесняйтесь закрывать этот вопрос, если это необходимо, я просто почувствовал необходимость документировать это и получить некоторую обратную связь.
- взято с комментарий на выпуск github. Вы можете найти больше информации в комментариях этому вопросу.
если вместо 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