커널은 PID 네임스페이스에서 첫 사용자 공간 프로세스를 PID 1로 시작합니다. 완전한 리눅스 시스템에서는 이 init 프로세스가 서비스 환경을 구성합니다. 컨테이너에서는 작은 init 래퍼나 애플리케이션 자체가 PID 1일 수 있지만 여전히 특별한 신호 및 자식 프로세스 회수 책임을 가집니다.
시스템 부팅 · 레슨 5
부팅 과정: Init
PID 1이 사용자 공간을 초기화하고 서비스를 감독하며 자식 프로세스를 회수하고 종료를 조정하는 방법을 알아봅니다.
PID 1의 책임
init 시스템은 일반적으로 다음 작업을 수행합니다.
- 서비스, 로그인, 마운트 및 기타 작업 단위를 시작하고 감독
- 의존성과 설정된 대상 상태에 따라 작업 순서 지정
- 고아가 된 자식 프로세스를 입양하고 회수
- 정책에 따라 서비스 실패에 대응
- 질서 있는 종료와 재부팅 조정
정확한 경계는 시스템마다 다릅니다. 장치 관리, 네트워킹, 로깅 및 예약 작업은 PID 1에 내장된 코드가 아니라 init이 감독하는 별도 프로그램일 수 있습니다.
PID 네임스페이스에서 PID 1에 특별히 부여되는 책임은 무엇입니까?
System V Init과 런레벨
전통적인 sysvinit은 /etc/inittab 같은 설정과 런레벨별 시작 및 종료 스크립트를 사용합니다. 런레벨은 운영 모드를 나타내지만 숫자 레벨의 의미는 배포판마다 다를 수 있습니다. 스크립트 순서는 관례에 따라 정해지며 배포판 도구가 이를 확장하거나 병렬화할 수 있습니다.
/etc/init.d/가 있다는 이유만으로 호스트의 활성 init 시스템을 추정하지 마십시오. PID 1이 다른 구현인 시스템에도 호환성 스크립트가 남아 있을 수 있습니다.
System V 런레벨은 무엇을 나타냅니까?
이벤트 및 의존성 기반 시스템
Upstart는 이벤트 구동 작업 모델을 도입했으며 구형 우분투 릴리스와 일부 다른 시스템에서 사용되었습니다. 현재는 주로 역사적 또는 레거시 운영 환경에서 중요합니다.
systemd는 현재 여러 범용 배포판에서 널리 사용됩니다. 서비스, 소켓, 마운트, 타이머, 장치, 대상 및 기타 리소스를 단위로 모델링합니다. 선언적 의존성과 활성화 메커니즘을 통해 필요한 순서를 유지하면서 독립적인 작업을 동시에 진행할 수 있습니다.
그 밖에 활발히 사용되는 init 및 감독 설계로 OpenRC, runit, s6 및 BusyBox init이 있습니다. “가장 최신”이라는 기준은 호환성 규칙으로 유용하지 않습니다. 실제 시스템이 무엇을 실행하는지 식별하고 해당 문서를 사용하십시오.
systemd는 서비스와 마운트 같은 관리 리소스를 어떻게 표현합니까?
실행 중인 Init 식별하기
설치된 파일을 보고 추측하지 말고 PID 1을 검사합니다.
$ ps -p 1 -o pid,comm,args=
$ readlink /proc/1/exe
권한, 컨테이너 및 네임스페이스에 따라 보이는 결과가 달라집니다. 컨테이너 안에서 실행한 명령은 호스트 init이 아니라 해당 네임스페이스의 PID 1을 보고합니다. 식별한 뒤에는 다른 init 계열의 명령을 섞지 말고 고유한 상태 및 로그 도구를 사용하십시오.
레거시 스크립트 디렉터리의 존재를 확인하는 것보다 PID 1을 검사하는 편이 나은 이유는 무엇입니까?
레슨 완료
부팅 과정: Init 완료
이제 init을 하나의 필수 구현이 아니라 역할로 설명할 수 있습니다.
PID 1을 서비스 초기화, 프로세스 회수 및 종료와 연결합니다.
System V 런레벨을 배포판에서 정의한 운영 모드로 이해합니다.
systemd 리소스와 의존성을 단위에 연결합니다.
도구를 선택하기 전에 관련 네임스페이스에서 실행 중인 PID 1을 검사합니다.