저는 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. 또한 /dev/tty(대신 ) 에 동일한 호스트 TTY 노드를 사용해 보았지만 c 5 0이 문제는 여전히 지속됩니다.
소스코드를 찾아보니 systemd-nspawn이런 내용이 있더라구요"전달된 pty"를 생성합니다., 여기서 컨테이너는 호스트 측으로 "전달"되는 새 PTY에서 실행됩니다. 교육 프로젝트에 비해 코드가 너무 복잡해서 실행 가능하지 않습니다.
컨테이너의 호스트 터미널을 어떻게 사용할 수 있나요?
세부 정보: 내 컨테이너 프로그램에는 clone(2)플래그 = 가 있는 자식이 하나만 있고 CLONE_NEWGROUP | CLONE_NEWNET | CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD자식은 기능(블랙리스트 지정)과 seccomp(화이트리스트 지정, syscall 목록에서 가져옴)를 설정합니다.도커), pivot_root(2)컨테이너 rootfs 이전 및 execve(2)대상 애플리케이션으로.
현재 Linux 5.3(Ubuntu 18.04 HWE)에서 실험 중이지만 최근 Linux 버전에서도 이것이 달라질 것으로 예상하지 않습니다.