Microsoft MVP성태의 닷넷 이야기
Linux: 89. pid 네임스페이스 구성으로 본 WSL 2 배포본의 계층 관계 [링크 복사], [링크+제목 복사],
조회: 6245
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 

(시리즈 글이 7개 있습니다.)
개발 환경 구성: 713. "WSL --debug-shell"로 살펴보는 WSL 2 VM의 리눅스 환경
; https://www.sysnet.pe.kr/2/0/13650

개발 환경 구성: 715. Windows - WSL 2 환경의 Docker Desktop 네트워크
; https://www.sysnet.pe.kr/2/0/13659

Linux: 88. WSL 2 리눅스 배포본 내에서의 pid 네임스페이스 구성
; https://www.sysnet.pe.kr/2/0/13771

Linux: 89. pid 네임스페이스 구성으로 본 WSL 2 배포본의 계층 관계
; https://www.sysnet.pe.kr/2/0/13772

Linux: 90. pid 네임스페이스 구성으로 본 WSL 2 + docker-desktop
; https://www.sysnet.pe.kr/2/0/13773

Linux: 91. Container 환경에서 출력하는 eBPF bpf_get_current_pid_tgid의 pid가 존재하지 않는 이유
; https://www.sysnet.pe.kr/2/0/13774

개발 환경 구성: 729. WSL 2 - Mariner VM 커널 이미지 업데이트 방법
; https://www.sysnet.pe.kr/2/0/13779




pid 네임스페이스 구성으로 본 WSL 2 배포본의 계층 관계

지난 글의 마지막 즈음에,

// Mariner VM 내에서 실행

# cat /proc/83194/status | grep NSpid
NSpid:  83194   3116    3059

리눅스 배포본 내에 뜬 프로세스가 3개의 네임스페이스를 거쳐 격리된 것이라고 설명했습니다. 이번 글에서는 이에 대해 좀 더 자세하게 살펴보겠습니다.




테스트를 위해 Ubuntu 20.04 WSL 인스턴스에서 sleep을 하나 실행해 둡니다.

// Ubuntu WSL 인스턴스 내에서 실행

$ sleep 680001 &
[1] 4419

// 4419 프로세스의 pid namespace 확인
$ ls -l /proc/4419/ns/pid
lrwxrwxrwx 1 testusr testusr 0 Oct 17 14:46 /proc/4419/ns/pid -> 'pid:[4026532257]'

그다음 debug shell로 연결한 환경에서 저 프로세스를 확인하면,

c:\temp> wsl --debug-shell

// 현재 환경의 pid namespace 확인
# ls -l /proc/1/ns/pid
lrwxrwxrwx 1 root root 0 Oct 17 01:11 /proc/1/ns/pid -> 'pid:[4026531836]'

// Ubuntu WSL 인스턴스 내에서 실행한 프로세스 확인
# ps aux | grep [s]leep
wslg       48950  0.0  0.0   7240   588 ?        S    05:40   0:00 sleep 680001

# cat /proc/48950/status | grep NSpid
NSpid:  48950   4578    4419

이렇게 정리가 됩니다.

pid:[4026531836] Mariner VM에 속한 pid namespace
  |- 48950 (sleep의 pid)
  ㄴ pid:[????????] (unknown)
       |- 4578 (sleep의 pid)
       ㄴ pid:[4026532257] Ubuntu WSL 인스턴스에 속한 pid namespace
            ㄴ 4419 (sleep의 pid)

그렇다면 4578 pid로 나타난 네임스페이스는 뭘까요?




예전에, wsl --debug-shell과 함께 wsl --system을 언급한 적이 있습니다.

c:\temp> wsl --help
...[생략]..
    --system
        Launches a shell for the system distribution.
...[생략]..

이걸로 들어가 보면,

c:\temp> wsl --system

$ ps aux | grep [s]leep
wslg        4578  0.0  0.0   7240   588 ?        S    14:40   0:00 sleep 680001

오호~~~ 우리가 찾던 바로 그 4578 프로세스가 나왔습니다. 그리고 그 사이에 낀 네임스페이스 격리를 Mariner VM 수준에서 다음과 같이 추적할 수 있습니다.

// Mariner VM 내에서 실행

# lsns -t pid 4026532257
  PID  PPID USER COMMAND
  226   221 root /sbin/init
  227   226 root |-/init
  248   227 root | |-plan9 --control-socket 6 --log-level 4 --server-fd 7 --pipe
  939   227 root | |-/bin/login -f
 1132   939 root | | `--bash
 1363   227 root | |-/init
...[생략]...

보면, 226 PID의 부모로 221이 나오는데요, 그것의 pid namespace를 살펴보면,

// Mariner VM 내에서 실행

# ls -l /proc/221/ns/pid
lrwxrwxrwx 1 root root 0 Oct 17 01:11 /proc/221/ns/pid -> 'pid:[4026532245]'

다른 값이 나왔습니다. 따라서 pid namespace 계층을 정리하면 대충 다음과 같이 나옵니다.

pid:[4026531836] Mariner VM에 속한 pid namespace
  |- 48950 (sleep의 pid)
  ㄴ pid:[4026532245] WSLg 격리
       |- 4578 (sleep의 pid)
       ㄴ pid:[4026532257] Ubuntu WSL 인스턴스에 속한 pid namespace
            ㄴ 4419 (sleep의 pid)




참고로, WSL 리눅스 인스턴스들이 언제나 저렇게 WSLg 쪽 네임스페이스에 속해 있지는 않습니다. 추가로 새롭게 설치한 Ubuntu 18.04의 경우에는,

$ sleep 180000 &
[1] 32

$ ls -l /proc/32/ns/pid
lrwxrwxrwx 1 testusr testusr 0 Oct 17 15:24 /proc/32/ns/pid -> 'pid:[4026532784]'

wsl --system 환경에서는 보이지 않았습니다.

c:\temp> wsl --system

$ ps aux | grep [s]leep
$

Mariner VM에서 확인해 보면,

// Mariner VM 내에서 실행

# ps aux | grep [s]leep
wslg       56564  0.0  0.0   7936   824 ?        S    06:24   0:00 sleep 180000

# cat /proc/56564/status | grep NSpid
NSpid:  56564   87      32

역시 3개의 격리 공간이 나오는데요, 이번에도 WSLg 레벨과 유사한 별도의 네임스페이스가 Ubuntu 18.04 인스턴스의 중간에 존재하는 것을 ppid를 추적해 살펴볼 수 있습니다.

// Mariner VM 내에서 실행

# lsns -t pid 4026532784
   PID   PPID USER COMMAND
 56297  56291 root /init
 ...[생략]...
56564  56336 wslg |     `-sleep 180000
 ...[생략]...

# ls -l /proc/56291/ns/pid
lrwxrwxrwx 1 root root 0 Oct 17 06:32 /proc/56291/ns/pid -> 'pid:[4026532771]'

이를 감안해 적용해 보면, 대충 이런 식의 WSL 2 배포본의 계층 구조를 유추할 수 있을 것입니다.

Mariner VM
   |- WSLg 격리
   |    |- 리눅스 배포본 A
   |    |- 리눅스 배포본 B
   |    .
   |    .
   |    ㄴ 리눅스 배포본 N
   |- Non-WSLg 격리
   |    ㄴ 리눅스 배포본 N
   .
   .
   ㄴ Non-WSLg 격리
        ㄴ 리눅스 배포본 N




또 한 가지 유의해야 할 점이 있다면, WSLg를 설정을 통해 아예 비활성화시킬 수 있다는 점입니다. (옵션 변경 후 "wsl --shutdown" 명령을 실행해야 적용됩니다.)

// 혹은, wslsettings.exe를 이용해 GUI 환경에서 편집할 수 있습니다.

C:\temp> type %USERPROFILE%\.wslconfig
[wsl2]
guiApplications=false

그리고 이 옵션을 false로 설정한 경우 "wsl --system" 명령어가 동작하지 않습니다. (사실, 거의 쓸 일이 없어 전혀 불편하지 않겠지만.)

C:\temp> wsl --system
GUI application support is disabled via C:\Users\testusr\.wslconfig or /etc/wsl.conf.
Error code: Wsl/Service/CreateInstance/WSL_E_GUI_APPLICATIONS_DISABLED




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







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

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

비밀번호

댓글 작성자
 




... 46  47  48  49  50  51  52  53  54  [55]  56  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12598정성태4/14/202119721.NET Framework: 1037. openssl의 PEM 개인키 파일을 .NET RSACryptoServiceProvider에서 사용하는 방법 (2)파일 다운로드1
12597정성태4/13/202118582개발 환경 구성: 569. csproj의 내용을 공통 설정할 수 있는 Directory.Build.targets / Directory.Build.props 파일
12596정성태4/12/202117891개발 환경 구성: 568. Windows의 80 포트 점유를 해제하는 방법
12595정성태4/12/202118417.NET Framework: 1036. SQL 서버 - varbinary 타입에 대한 문자열의 CAST, CONVERT 변환을 C# 코드로 구현
12594정성태4/11/202117839.NET Framework: 1035. C# - kubectl 명령어 또는 REST API 대신 Kubernetes 클라이언트 라이브러리를 통해 프로그래밍으로 접근 [1]파일 다운로드1
12593정성태4/10/202118399개발 환경 구성: 567. Docker Desktop for Windows - kubectl proxy 없이 k8s 대시보드 접근 방법
12592정성태4/10/202118009개발 환경 구성: 566. Docker Desktop for Windows - k8s dashboard의 Kubeconfig 로그인 및 Skip 방법
12591정성태4/9/202122076.NET Framework: 1034. C# - byte 배열을 Hex(16진수) 문자열로 고속 변환하는 방법 [2]파일 다운로드1
12590정성태4/9/202118537.NET Framework: 1033. C# - .NET 4.0 이하에서 Console.IsInputRedirected 구현 [1]
12589정성태4/8/202119103.NET Framework: 1032. C# - Environment.OSVersion의 문제점 및 윈도우 운영체제의 버전을 구하는 다양한 방법 [1]
12588정성태4/7/202121416개발 환경 구성: 565. PowerShell - New-SelfSignedCertificate를 사용해 CA 인증서 생성 및 인증서 서명 방법
12587정성태4/6/202122786개발 환경 구성: 564. Windows 10 - ClickOnce 배포처럼 사용할 수 있는 MSIX 설치 파일 [1]
12586정성태4/5/202119632오류 유형: 710. Windows - Restart-Computer / shutdown 명령어 수행 시 Access is denied(E_ACCESSDENIED)
12585정성태4/5/202118435개발 환경 구성: 563. 기본 생성된 kubeconfig 파일의 내용을 새롭게 생성한 인증서로 구성하는 방법
12584정성태4/1/202119674개발 환경 구성: 562. kubeconfig 파일 없이 kubectl 옵션만으로 실행하는 방법
12583정성태3/29/202120071개발 환경 구성: 561. kubectl 수행 시 다른 k8s 클러스터로 접속하는 방법
12582정성태3/29/202120034오류 유형: 709. Visual C++ - 컴파일 에러 error C2059: syntax error: '__stdcall'
12581정성태3/28/202119913.NET Framework: 1031. WinForm/WPF에서 Console 창을 띄워 출력하는 방법 (2) - Output 디버깅 출력을 AllocConsole로 우회 [2]
12580정성태3/28/202117639오류 유형: 708. SQL Server Management Studio - Execution Timeout Expired.
12579정성태3/28/202118408오류 유형: 707. 중첩 가상화(Nested Virtualization) - The virtual machine could not be started because this platform does not support nested virtualization.
12578정성태3/27/202118798개발 환경 구성: 560. Docker Desktop for Windows 기반의 Kubernetes 구성 (2) - WSL 2 인스턴스에 kind가 구성한 k8s 서비스 위치
12577정성태3/26/202120194개발 환경 구성: 559. Docker Desktop for Windows 기반의 Kubernetes 구성 - WSL 2 인스턴스에 kind 도구로 k8s 클러스터 구성
12576정성태3/25/202118550개발 환경 구성: 558. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 (2) - k8s 서비스 위치
12575정성태3/24/202117049개발 환경 구성: 557. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 [1]
12574정성태3/23/202122724.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드)
12573정성태3/22/202120074개발 환경 구성: 556. WSL 인스턴스 초기 설정 명령어 [1]
... 46  47  48  49  50  51  52  53  54  [55]  56  57  58  59  60  ...