저는 Linux 컨테이너 기술을 배우고 있으며 최소한의 컨테이너 구현을 직접 작성했습니다. 나는 현재 컨테이너 프로세스의 콘솔/터미널에 대해 혼란스러워합니다. 컨테이너 /dev/console대신에 컨테이너 내에서 제어 터미널을 "재사용"하고 있기 때문입니다.c 5 1
/proc/self/fd/0현재 터미널을 확인하고 해당 장치 노드(기본 및 보조)를 읽고 /proc/self/fd/2검색된 장치 노드를 사용하여 컨테이너에 mknod(2)노드를 만듭니다 ./dev/console
PID 1(PID 네임스페이스에서)과 같은 일반 애플리케이션을 실행할 때는 괜찮아 보이지만 /bin/shinit 시스템을 통과할 때는 그렇지 않습니다(저는 이를 위해 BusyBox를 사용합니다).
이것은 내 /etc/inittabBusyBox rootfs입니다.
::sysinit:/bin/true
::respawn:-/bin/sh
그러나 init에 의해 생성된 쉘은 항상 can't access tty; job control turned off. 또한 TTY 노드 /dev/tty(대신 ) 와 동일한 호스트를 사용해 보았지만 c 5 0문제가 지속됩니다.
소스코드를 보다 systemd-nspawn가 발견했어요"전달 pty" 만들기, 여기서 컨테이너는 호스트 측으로 "전달"되는 새 PTY에서 실행됩니다. 이 코드는 내 교육 프로젝트에 비해 너무 복잡하므로 적합하지 않습니다.
컨테이너의 호스트 터미널을 어떻게 사용하나요?
세부 정보: 내 컨테이너 프로그램에는 기능(블랙리스트) 및 seccomp(화이트리스트)를 설정하는 clone(2)플래그가 있는 하위 키가 하나만 있습니다. CLONE_NEWGROUP | CLONE_NEWNET | CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD시스템 호출 목록은 다음에서 가져옵니다.루스트어바웃), 그런 다음 pivot_root(2)컨테이너 rootfs 및 execve(2)대상 애플리케이션으로 이동합니다.
현재 Linux 5.3(Ubuntu 18.04 HWE)에서 실험 중이지만 최근 Linux 버전에서는 이것이 다를 것으로 예상하지 않습니다.