Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

"WSL --debug-shell"로 살펴보는 WSL 2 VM의 리눅스 환경

지난 글에서도 언급했지만,

Windows - WSL 2의 네트워크 통신 방법 - 세 번째 이야기 (같은 IP를 공유하는 WSL 2 인스턴스)
; https://www.sysnet.pe.kr/2/0/13647

WSL 2는 Hyper-V VM 위에 (다소 특별하게) 올라오는 Full Linux 운영체제입니다. 그리고, 우리가 흔히 알고 있는 Ubuntu 20.04 같은 배포본들은 그 운영체제 위에서 Container의 하나로 실행되는 인스턴스입니다.

그러니까, WSL 2는 하나의 VM 위에서 여러 개의 Container가 운영되는 방식이고, 그 Container 각각이 Ubuntu 20.04, Fedora 33, CentOS 8, Kali Linux 배포본 등이 되는 것입니다.

만약 WSL 2 인스턴스가 하나도 실행 중이지 않다면,

C:\temp> wsl -l -v
  NAME                    STATE           VERSION
* Ubuntu-20.04            Stopped         2
  docker-desktop          Stopped         2
  docker-desktop-data     Stopped         2

해당 리눅스 VM도 띄워놓지 않습니다. 그런 경우, 그 VM 자체의 shell로 진입하려는 명령어는 동작하지 않습니다.

// wsl --debug-shell
// ; https://renenyffenegger.ch/notes/Windows/dirs/Windows/System32/wsl_exe/debug-shell

C:\temp> wsl --debug-shell
The system cannot find the file specified.
Error code: Wsl/DebugShell/ERROR_FILE_NOT_FOUND

하지만, 1개의 WSL 인스턴스라도 실행 중이라면, 설령 그것이 (0-byte /init만 가지고 있다고 표현되는) docker-desktop-data라고 해도,

// "wsl -d docker-desktop-data" 명령어로 구동

c:\temp> wsl -l -v
  NAME                    STATE           VERSION
* Ubuntu-20.04            Stopped         2
  docker-desktop          Stopped         2
  docker-desktop-data     Running         2

작업 관리자에는 다음의 VM 프로세스가 추가로 생성되고,

vmmemWSL
vmwp.exe

shell 진입이 가능합니다.

// Running 상태의 인스턴스가 "docker-desktop-data" 하나라면 잠시 후에 VM이 자동 종료함

c:\temp> wsl --debug-shell

Welcome to CBL-Mariner 2.0.20240112 (x86_64) - Kernel 5.15.153.1-microsoft-standard-WSL2 (hvc1)
TESTPC login: root (automatic login)

위의 출력에도 나오지만, 이 운영체제의 커널은 마이크로소프트가 커스터마이징한 것이고, 배포본 종류는 CBL-Mariner라고 합니다.

CBL-Mariner
 - an internal Linux distribution for Microsoft's cloud infrastructure and edge products and services.
; https://github.com/microsoft/azurelinux




예를 들어, 이렇게 3개의 WSL Instance가 실행 중이라면,

c:\temp> wsl -l -v
  NAME                    STATE           VERSION
* Ubuntu-20.04            Running         2
  docker-desktop          Running         2
  docker-desktop-data     Running         2

wsl --debug-shell 내부에서는 각각에 대응한 WSLGd 프로세스를 볼 수 있습니다.

# cat /etc/wsl.conf
command=/usr/bin/WSLGd

# ps -oeuser,pid,ppid,cmd -C WSLGd
EUSER      PID  PPID CMD
root       314   298 /usr/bin/WSLGd
root      2306  2297 /usr/bin/WSLGd
root      2350  2341 /usr/bin/WSLGd

해당 프로세스들은 pid=1인 /init이 실행한 또 다른 /init을 부모로 둡니다.

#  ps -oeuser,pid,ppid,cmd --ppid 1
EUSER      PID  PPID CMD
...[생략]...
root       298     1 /init
root      2297     1 /init
root      2341     1 /init

예를 들어, 2297 init을 부모로 프로세스 트리를 쭉 따라가 보면,

2297     1 /init
  2298  2297 /init
    2384  2298 /init
      2385  2384 /init
        2386  2385 wsl-bootstrap run --base-image /c/Program Files/Docker/Docker/resources/docker-desktop.iso --cli-iso /c/Program Files/Docker/Docker/resources/wsl/docker-wsl-cli.iso
          2417  2386 unshare -muinpf --propagation=unchanged --kill-child /usr/local/bin/wsl-bootstrap jump
            2420  2417 /init
              2433  2420 /init services
                2502  2433 /usr/bin/runc run --preserve-fds=3 01-docker
                  3910  2502 /usr/bin/containerd-shim-runc-v2 -namespace moby -id 4e51b5a3b0b8741c27ad94663f5c6cbad139af4ad37eccb7eef8397e235bca96 -address /run/containerd/containerd.sock

저렇게 docker desktop을 구성하는 컨테이너까지 흘러가게 됩니다. 즉, "docker-desktop" (컨테이너로 실행 중인) WSL 2 인스턴스 내부의 프로세스를 볼 수 있습니다.

마찬가지로, (예를 들어) "Ubuntu 20.04" WSL 2 인스턴스를 실행한 다음 거기 실행된 프로세스를 아무거나 하나 열거하고,

// "Ubuntu 20.04" WSL 2 인스턴스에서 실행

$ ps -oeuser,pid,ppid,cmd --pid 333
EUSER      PID  PPID CMD
root       333     1 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers

$ ps -oeuser,pid,ppid,cmd --pid 1
EUSER      PID  PPID CMD
root         1     0 /sbin/init

그에 해당하는 프로세스를 CBL-Mariner에서 추적하면 이런 트리가 구성됩니다.

298     1 /init
  304   298 /sbin/init
    666   304 /usr/bin/python3 /usr/bin/networkd-dispatcher --run-startup-triggers

정말 하나의 컴퓨터(VM)에서 (namespace만 구분돼) 모든 WSL 2 인스턴스가 실행되는 것이 맞죠? ^^

흥미로운 것은, 위의 결과를 보면, "Ubuntu 20.04"보다 "docker-desktop"이 /init에 대한 단계가 더 많습니다. 제가 리알못이지만, 아마도 "docker-desktop"도 일반적인 하나의 WSL 2 배포본으로 동작하지만 단순히 bootstrapper 용도에 불과한 듯합니다. 즉, "docker-desktop"은 일종의 껍데기 WSL 2 배포본이고, 실질적인 docker 서비스는 그것에서 다시 실행한 컨테이너에서 하는 것입니다. 이에 대한 구조를 다음의 그림에서 확인할 수 있습니다.

Introducing the Docker Desktop WSL 2 Backend
; https://www.docker.com/blog/new-docker-desktop-wsl2-backend/

archtecture_wsl2_1.png

그러니까, 위의 그림에 따르면 "wsl --debug-shell"로 진입한 환경은 "WSL 2 Utility VM"의 운영체제에 해당하고, "docker-desktop"은 그 VM 위에서 실행되는 "Bootstrapping distro"이며, 실제 docker 서비스는 다시 그것에서 구성한 "LinuxKit" 컨테이너에서 이뤄지는 것입니다.

CBL-Mariner (마이크로소프트가 제공하는 "WSL 2 Utility VM" 운영체제), "wsl --debug-shell"로 연결 가능
    - 컨테이너로 실행 중인 다른 배포본 (예: Ubuntu-20.04, Kali-Linux), "wsl -d [배포본명]"으로 연결 가능
    - bootstrapping을 위한 배포본 (docker-desktop), "wsl -d docker-desktop"으로 연결 가능
        - (실질적인 docker 기능을 담당하는) LinuxKit 배포본

참고로 LinuxKit도 공개돼 있습니다.

linuxkit/linuxkit
; https://github.com/linuxkit/linuxkit

(혹시, 리눅스 전문가가 계시다면 위의 설명이 맞게 정리된 것인지 덧글 부탁드립니다. ^^)




CBL-Mariner 운영체제로의 진입은 "wsl --debug-shell" 명령어, 또는 "wsl --system"으로 할 수 있습니다.

당연하겠지만, "컨테이너로 실행 중인 다른 배포본"의 shell에 진입하는 것도 가능합니다. 사실 이것은 우리가 그동안 무심코 해왔던 건데요, 예를 들어, Ubuntu 20.04 배포본을 설치한 후 윈도우의 "시작" 메뉴에 설치된 "Ubuntu 20.04"를 클릭하면 해당 배포본의 Shell로 진입할 수 있었습니다. 혹은, 이 과정을 명령행으로는 "wsl -d" 옵션으로 수행할 수 있습니다.

c:\temp> wsl -d Ubuntu-20.04

물론 "docker-desktop" 배포본에도 위의 명령어를 이용하면 shell 진입이 가능합니다.

c:\temp> wsl -d docker-desktop

# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:15:5D:73:ED:54
          inet addr:172.19.132.144  Bcast:172.19.143.255  Mask:255.255.240.0
          ...[생략]...

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          ...[생략]...

// 또한, docker-desktop은 현재 alpine 리눅스이므로 apk를 이용한 패키지 설치가 가능합니다.
# apk add nano
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/main/x86_64/APKINDEX.tar.gz
fetch https://dl-cdn.alpinelinux.org/alpine/v3.19/community/x86_64/APKINDEX.tar.gz
(1/1) Installing nano (7.2-r1)
Executing busybox-1.36.1-r15.trigger
OK: 15 MiB in 54 packages

게다가 보는 바와 같이 해당 환경에서의 IP를 비롯한 시스템 환경이 다른 WSL 2 인스턴스에서의 환경과 유사한 레벨로 구성되었습니다.

참고로, "docker-desktop-data"는 "data store" 역할만 하기 때문에 오류가 발생합니다.

c:\temp> wsl -d docker-desktop-data
...[생략]...
<3>WSL (22) ERROR: CreateProcessEntryCommon:334: getpwuid(0) failed 2
<3>WSL (22) ERROR: CreateProcessEntryCommon:505: execvpe /bin/sh failed 2
<3>WSL (22) ERROR: CreateProcessEntryCommon:508: Create process not expected to return




VM의 CBL-Mariner 운영체제도 하나의 완벽한 리눅스 환경이므로 (소개 페이지에 "Fedora Project"가 언급되는 걸로 봐서) yum으로 추가 패키지를 설치할 수 있습니다.

// "wsl --shutdown" 등으로 VM이 종료되면,
// 이후 다시 "--debug-shell"로 진입했을 때 패키지도 새롭게 설치해야 합니다.

# yum install lsb-release -y
...[생략]...
Installing/Updating: lsb-release-3.1-1.cm2.noarch

# lsb_release -a
LSB Version:    n/a
Distributor ID: Mariner
Description:    CBL-Mariner 2.0.20240112
Release:        2.0.20240112
Codename:       Mariner

# cat /etc/os-release
NAME="Common Base Linux Mariner"
VERSION="2.0.20240112"
ID=mariner
VERSION_ID="2.0"
PRETTY_NAME="CBL-Mariner/Linux"
ANSI_COLOR="1;34"
HOME_URL="https://aka.ms/cbl-mariner"
BUG_REPORT_URL="https://aka.ms/cbl-mariner"
SUPPORT_URL="https://aka.ms/cbl-mariner"

당연히, IP 역시 WSL 2 VM으로써 "vEthernet (WSL)"에 연결돼 최초 할당받은 것이므로 WSL 배포본에서 볼 수 있었던 그 IP와 동일합니다.

# yum install net-tools -y
...[생략]...

# ifconfig

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.132.144  netmask 255.255.240.0  broadcast 172.19.143.255
        ...[생략]...

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        ...[생략]...

어찌 보면, WSL 2가 구성되었다는 것만으로도 여러분은 이미 Linux VM 하나를 소유한 것이나 다름없습니다. ^^




wsl debug shell은 일단 들어가면 나올 수 없습니다. 가령 'exit' 명령어를 입력하면 대부분 'logout'이라고만 나오고 멈출 것입니다. 이후 다른 cmd 창에서 다시 들어가려고 해도 ERROR_PIPE_BUSY 오류가 나올 텐데요,

C:\temp> wsl --debug-shell
All pipe instances are busy.
Error code: Wsl/DebugShell/ERROR_PIPE_BUSY

매끄러운 해결책은 알 수 없었고, 제 경우에는 그냥 "wsl --shutdown"을 해 vmwp.exe 자체를 종료한 후 다시 (WSL 2 인스턴스를 띄우고) 진입했습니다. 관련해서 아래의 이슈를 보면,

wsl --debug-shell not exiting #9535
; https://github.com/microsoft/WSL/issues/9535>

일단 그렇게 동작하는 것은 맞는다고 합니다. 따라서, 이런 불편함이 있으므로 가능하다면 그냥 "--debug-shell"보다는 "--system" 옵션으로 접속해 살펴보는 것이 좋겠습니다. 단지 "--system"은 기본적으로 "wslg" 사용자로 로그인하기 때문에 "root" 권한이 요구되는 작업은 할 수 없는데, 대신 "-u root" 옵션을 추가해 이런 문제를 보완할 수 있습니다. (그 외에도 --debug-shell과 --system에는 차이가 있긴 합니다.)

C:\temp> wsl --system
wslg $ yum install iputils
Error(1601) : Operation not permitted. You have to be root.
$ exit
logout

C:\temp> wsl --system -u root
root $ yum install iputils -y
...[생략]...
Installing/Updating: iputils-20211215-2.cm2.x86_64




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/1/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13678정성태7/15/2024214VS.NET IDE: 191. Visual Studio 2022 - .NET 5 프로젝트를 Docker Support로 실행했을 때 오류
13677정성태7/15/2024214오류 유형: 916. MSBuild - CheckEolTargetFramework (warning NETSDK1138)
13676정성태7/14/2024213Linux: 75. gdb에서 glibc의 함수에 Breakpoint 걸기
13675정성태7/13/2024479C/C++: 166. C/C++ - DLL에서 template 함수를 export하는 방법파일 다운로드1
13674정성태7/13/2024479오류 유형: 915. Unhandled Exception: Microsoft.Diagnostics.NETCore.Client.ServerNotAvailableException: Unable to connect to Process
13673정성태7/11/2024524닷넷: 2274. C# 13 - 신규 이스케이프 시퀀스 '\e'파일 다운로드1
13672정성태7/10/2024517닷넷: 2273. IIS - (프로세스 종료 없는) AppDomain Recycle
13671정성태7/10/2024540오류 유형: 914. Package ca-certificates is not installed.
13669정성태7/9/2024719오류 유형: 913. C# - AOT StaticExecutable 정적 링킹 시 빌드 오류
13668정성태7/8/2024788개발 환경 구성: 716. Hyper-V - Ubuntu 22.04 Generation 2 유형의 VM 설치
13667정성태7/7/2024775닷넷: 2272. C# - 리눅스 환경에서의 Hyper-V Socket 연동 (AF_VSOCK)파일 다운로드1
13666정성태7/7/2024957Linux: 74. C++ - Vsock 예제 (Hyper-V Socket 연동)파일 다운로드1
13665정성태7/6/20241013Linux: 73. Linux 측의 socat을 이용한 Hyper-V 호스트와의 vsock 테스트파일 다운로드1
13663정성태7/5/20241004닷넷: 2271. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)의 VMID Wildcards 유형파일 다운로드1
13662정성태7/4/20241261닷넷: 2270. C# - WSL 2 VM의 VM ID를 알아내는 방법 - Host Compute System API파일 다운로드1
13661정성태7/3/2024990Linux: 72. g++ - 다른 버전의 GLIBC로 소스코드 빌드
13660정성태7/3/20241163오류 유형: 912. Visual C++ - Linux 프로젝트 빌드 오류
13659정성태7/1/20241176개발 환경 구성: 715. Windows - WSL 2 환경의 Docker Desktop 네트워크
13658정성태6/28/20241190개발 환경 구성: 714. WSL 2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법 - 두 번째 이야기
13657정성태6/27/20241395닷넷: 2269. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)을 위한 EndPoint 사용자 정의
13656정성태6/27/20241335Windows: 264. WSL 2 VM의 swap 파일 위치
13655정성태6/24/20241447닷넷: 2269. C# - Win32 Resource 포맷 해석파일 다운로드1
13654정성태6/24/20241372오류 유형: 911. shutdown - The entered computer name is not valid or remote shutdown is not supported on the target computer.
13653정성태6/22/20241301닷넷: 2268. C# 코드에서 MAKEINTREOURCE 매크로 처리
13652정성태6/21/20241435닷넷: 2267. C# - Linux 환경에서 (Reflection 없이) DLL AssemblyFileVersion 구하는 방법파일 다운로드2
[1]  2  3  4  5  6  7  8  9  10  11  12  13  14  15  ...