Microsoft MVP성태의 닷넷 이야기
Linux: 89. pid 네임스페이스 구성으로 본 WSL 2 배포본의 계층 관계 [링크 복사], [링크+제목 복사],
조회: 5186
글쓴 사람
정성태 (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)
12587정성태4/6/202121081개발 환경 구성: 564. Windows 10 - ClickOnce 배포처럼 사용할 수 있는 MSIX 설치 파일 [1]
12586정성태4/5/202117946오류 유형: 710. Windows - Restart-Computer / shutdown 명령어 수행 시 Access is denied(E_ACCESSDENIED)
12585정성태4/5/202116898개발 환경 구성: 563. 기본 생성된 kubeconfig 파일의 내용을 새롭게 생성한 인증서로 구성하는 방법
12584정성태4/1/202118075개발 환경 구성: 562. kubeconfig 파일 없이 kubectl 옵션만으로 실행하는 방법
12583정성태3/29/202119002개발 환경 구성: 561. kubectl 수행 시 다른 k8s 클러스터로 접속하는 방법
12582정성태3/29/202118391오류 유형: 709. Visual C++ - 컴파일 에러 error C2059: syntax error: '__stdcall'
12581정성태3/28/202118369.NET Framework: 1031. WinForm/WPF에서 Console 창을 띄워 출력하는 방법 (2) - Output 디버깅 출력을 AllocConsole로 우회 [2]
12580정성태3/28/202116209오류 유형: 708. SQL Server Management Studio - Execution Timeout Expired.
12579정성태3/28/202116796오류 유형: 707. 중첩 가상화(Nested Virtualization) - The virtual machine could not be started because this platform does not support nested virtualization.
12578정성태3/27/202117234개발 환경 구성: 560. Docker Desktop for Windows 기반의 Kubernetes 구성 (2) - WSL 2 인스턴스에 kind가 구성한 k8s 서비스 위치
12577정성태3/26/202118894개발 환경 구성: 559. Docker Desktop for Windows 기반의 Kubernetes 구성 - WSL 2 인스턴스에 kind 도구로 k8s 클러스터 구성
12576정성태3/25/202116923개발 환경 구성: 558. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 (2) - k8s 서비스 위치
12575정성태3/24/202115497개발 환경 구성: 557. Docker Desktop for Windows에서 DockerDesktopVM 기반의 Kubernetes 구성 [1]
12574정성태3/23/202121007.NET Framework: 1030. C# Socket의 Close/Shutdown 동작 (동기 모드)
12573정성태3/22/202118404개발 환경 구성: 556. WSL 인스턴스 초기 설정 명령어 [1]
12572정성태3/22/202117738.NET Framework: 1029. C# - GC 호출로 인한 메모리 압축(Compaction)을 확인하는 방법파일 다운로드1
12571정성태3/21/202115781오류 유형: 706. WSL 2 기반으로 "Enable Kubernetes" 활성화 시 초기화 실패 [1]
12570정성태3/19/202121092개발 환경 구성: 555. openssl - CA로부터 인증받은 새로운 인증서를 생성하는 방법
12569정성태3/18/202121461개발 환경 구성: 554. WSL 인스턴스 export/import 방법 및 단축 아이콘 설정 방법
12568정성태3/18/202114798오류 유형: 705. C# 빌드 - Couldn't process file ... due to its being in the Internet or Restricted zone or having the mark of the web on the file.
12567정성태3/17/202116859개발 환경 구성: 553. Docker Desktop for Windows를 위한 k8s 대시보드 활성화 [1]
12566정성태3/17/202116668개발 환경 구성: 552. Kubernetes - kube-apiserver와 REST API 통신하는 방법 (Docker Desktop for Windows 환경)
12565정성태3/17/202113428오류 유형: 704. curl.exe 실행 시 dll not found 오류
12564정성태3/16/202114286VS.NET IDE: 160. 새 프로젝트 창에 C++/CLI 프로젝트 템플릿이 없는 경우
12563정성태3/16/202117161개발 환경 구성: 551. C# - JIRA REST API 사용 정리 (3) jira-oauth-cli 도구를 이용한 키 관리
12562정성태3/15/202117932개발 환경 구성: 550. C# - JIRA REST API 사용 정리 (2) JIRA OAuth 토큰으로 API 사용하는 방법파일 다운로드1
... 46  47  48  49  50  51  52  53  [54]  55  56  57  58  59  60  ...