시스템 5는 init이야기의 작은 부분만을 알려줄 것입니다.

Linux 세계에는 일종의 근시가 있습니다. 사람들은 init전통적이면서 시작하기에 가장 좋은 "시스템 5"라는 것을 사용한다고 생각합니다 . 그렇지 않다.

우선, 전통은 실제로 이 사람들이 말하는 것과는 다릅니다. 시스템 5 init와 시스템 5는 rcAT&T UNIX 시스템 5로 거슬러 올라갑니다. 이는 Linux-Mandrake의 첫 번째 버전 이후인 지금(가령) 우리가 지금(가령) 첫 번째 UNIX 이후인 것과 거의 같습니다.

UNIX의 첫 번째 버전에는 해당 init되지 않았습니다 rc. 초판 어셈블리 언어 init(누구의 코드이미Warren Toomey et al.이 복원하고 제공했습니다.)는 12개의 프로세스를 직접 생성 및 다시 생성하고 getty, 내장 테이블에서 3개의 하드와이어 파일 시스템을 마운트하고, 이름이 사용자인 사용자의 홈 디렉터리에서 직접 프로그램을 실행합니다 mel. 이 getty테이블은 프로그램 이미지에도 직접 위치합니다.

UNIX 시스템 5 소위 "전통적인" Linux 초기화 시스템이 등장하기까지 또 다른 10년이 지났습니다. 1992년에 Miquel van Smoorenburg는 Linux init+ rc및 관련 도구를 (다시) 작성했습니다. 이 도구 init는 실제로 UNIX System 5의 소프트웨어는 아니었지만 현재 사람들은 "System 5" 라고 부릅니다 init.

System 5 init/는 rc최고의 출발점이 아닙니다. systemd에 대한 지식을 늘려도 필요한 것의 절반에도 미치지 못합니다. 지난 20년 동안 (Linux 및 BSD용) init 시스템 설계 영역에서 많은 작업이 이루어졌습니다. 다양한 엔지니어링 결정이 논의, 공식화, 설계, 구현 및 실행됩니다. Commercial Unices도 많은 작업을 수행합니다.

연구 및 연구에 사용 가능한 기존 시스템

이것은 일부 주요 초기화 시스템의 불완전한 목록입니다.밖의이 두 가지 모두와 그 중 한두 가지(여러 가지) 요점은 다음과 같습니다.

• 요아킴 닐센의유한한 가치보다 이해하기 쉬운 구성 파일을 사용하는 방법을 택했습니다.
• 펠릭스 폰 라이트너미니데이터베이스 구성 시스템인 파일 시스템, 작은 메모리 공간, init시작된 항목 간의 시작/중지 종속성을 선택합니다.
• 게릿 펩의달리다아까 설명했던 곳으로 갔어요방금 4개의 쉘 스크립트를 생성했습니다.방법.
• 초기화NG종속성, 명명된 대상, 여러 구성 파일 및 보다 유연한 구성 구문을 갖고 하위 프로세스에 대해 더 많은 설정을 로드하도록 설계되었습니다.
• 갑자기 나타나다우리는 서비스와 상호 의존성으로 인해 발생하는 이벤트와 작업이 아닌 시스템을 모델링하기 위해 완전한 재설계를 거쳤습니다.
• 디자인간식모든 서비스 관리( getty생성 및 좀비 수확까지 포함)를 별도의 서비스 관리자에게 맡기는 것을 포함합니다.오직운영 체제별 "API" 장치/기호 링크/디렉토리 및 시스템 이벤트를 처리합니다.
• 사인매우 간단한 초기화입니다. 수행하는 작업은 /bin/rc.init프로그램 시작, 파일 시스템 마운트 등입니다. 이를 위해 다음과 같은 것을 사용할 수 있습니다초소형 컴퓨터.

또한 약 10년 전에 daemontools 사용자와 다른 사용자 사이에 프로세스 #1로 사용하는 것에 대한 논의가 있었는데, svscan그 결과 다음과 같은 결과가 나왔습니다.프로세스 1 연구로서의 Paul Jarc의 svscan,게릿 펩의 생각, 그리고Laurent Bercot의 svscan 프로세스 1.

이는 프로세스 #1 프로그램의 역할을 소개합니다.

프로세스 #1 프로그램은 무엇을 합니까?

프로세스 #1이 "해야 하는" 작업에 대한 개념은 본질적으로 주관적입니다. 의미있는목적디자인 표준 프로세스는 무엇입니까 #1적어도 해야 한다하다. 커널은 이에 대한 몇 가지 요구 사항을 제시합니다. 그리고 항상 운영 체제별로 수행해야 하는 다양한 작업이 있습니다. 프로세스 #1이 무엇인지에 관해서는전통적으로그렇다면 우리는 그 최소값에 도달하지 못했고 실제로 도달한 적도 없습니다.

다양한 운영 체제 커널 및 기타 프로그램에 의해 프로세스 #1에는 피할 수 없는 몇 가지 요구 사항이 있습니다.

fork()사람들은 사물을 처리하고 고아 프로세스의 상위 프로세스 역할을 하는 것이 프로세스 #1의 주요 기능이라고 말할 것입니다 . 아이러니하게도 이는 사실이 아니다. 고아 프로세스를 처리하는 것은 (설명된 대로 최근 Linux 커널의 경우)https://unix.stackexchange.com/a/177361/5132) 프로세스 #1에서 전용 프로세스와 같은 다른 프로세스로 크게 분해할 수 있는 시스템의 일부서비스 매니저. 이들 모두는 프로세스 #1 외부에서 실행되는 서비스 관리자입니다.

• IBM AIX srcmstr프로그램시스템 리소스 컨트롤러
• 게릿 펩의runsvdir루넷에서
• 다니엘 J. 번스타인svscandaemontools에서, Adam svscanSampson함대, 브루스 건터svscandaemontools-encore 및 Laurent Bercot 제공s6-svscans6부터
• 웨인 마샬의perpd범죄자로부터
• Solaris 10의 서비스 관리 도구
• service-managernosh 에서

다시 설명드리자면https://superuser.com/a/888936/38062, 전체 /dev/initctl아이디어가 프로세스 #1에 가까울 필요는 없습니다. 아이러니하게도 프로세스 #1에서 벗어날 수 있음을 입증한 것은 고도로 중앙화된 시스템이었습니다.

init대신 사람들이 임시 설계에서 일반적으로 잊어버리는 필수 사항은 커널 의미SIGINT등에서SIGPWRSIGWINCHhttps://unix.stackexchange.com/a/196471/5132, BSD 도구 세트 "알고 있다"는 SIGUSR1특정한 의미를 갖습니다. )

설치와 같이 피할 수 없거나 수행하지 않으면 큰 손실을 입을 수 있는 일회성 초기화 및 마무리 작업도 있습니다."API" 파일 시스템또는 파일 시스템 캐시를 플러시합니다.

"API" 파일 시스템을 다루는 기본 사항은 initROM의 첫 번째 UNIX 버전의 작동과 거의 다르지 않습니다. 즉, 프로그램에는 하드와이어된 정보 목록이 있고 mount()목록에 있는 모든 항목을 저장하기만 하면 됩니다. init이 메커니즘은 BSD(sic!)에서 nosh, systemd에 이르는 시스템에서 찾을 수 있습니다 system-manager.

"시스템을 간단한 쉘로 설정"

보시다시피, init=/bin/sh"API" 파일 시스템은 유형 exit(https://unix.stackexchange.com/a/195978/5132), 일반적으로 시스템을 최소한으로 사용 가능하게 만드는 작업을 수동으로 수행하는 것은 (수퍼) 사용자에게 맡겨집니다.

명시된 디자인 목표에 대한 좋은 기초를 갖기 위해 프로세스 #1 프로그램에서 사람들이 실제로 무엇을 해야 하는지에 대한 좋은 아이디어를 얻으려면 가장 좋은 방법은 Gerrit Pape의 runit(Felix von ) in action Leitner의 minit와 system-managernosh 패키지의 프로그램이 중복됩니다. 처음 두 개는 미니멀리즘에 대한 두 가지 시도를 보여주지만 여전히 피할 수 없는 문제를 다루고 있습니다.

후자는 system-manager어떤 "API" 파일 시스템이 마운트되는지, 어떤 초기화 작업이 실행되는지, 시스템에서 어떤 신호가 처리되는지 자세히 설명하는 많은 수동 입력을 프로그램에 포함하기 때문에 유용하다고 생각됩니다.디자인에 의해시스템 관리자는 다른 세 가지 작업(서비스 관리자, 동반 로거, 상태 변경을 실행하는 프로그램)만 생성하고 프로세스 #1에서 피할 수 없는 작업만 수행합니다.

Debian의 System V init(다른 변형 및 변형이 있음)는 다음을 수행합니다.

• 런레벨을 입력하면 /etc/rcX.d/S*영숫자 순서로 스크립트가 호출됩니다. 여기서 X런레벨은 입니다. 이 스크립트는 실행 수준을 설정해야 합니다. 일반적인 설정은 데몬을 시작하고 해당 런레벨에 대한 설정 작업을 수행하는 것입니다. 이는 실행 레벨에 들어갈 때 일회성입니다.
• 런레벨에 있는 동안 /etc/inittab해당 런레벨 동안 활성화되어야 하는 데몬을 시작합니다. 이러한 데몬이 실행을 중지하면 다시 시작됩니다. 관리하려는 데몬이 있을 수 있지만 로그인하려면 init최소한 몇 개의 데몬이 필요합니다 . 로그인이 완료되면 종료한 다음 다시 시작하여 새 로그인 프롬프트를 표시합니다.gettygettyinit
  
  • 데몬이 너무 짧은 시간에 너무 많이 다시 시작되면 일시적으로 다시 시작하려는 시도가 중지됩니다.
  • 시작 스크립트가 런레벨에 들어갈 때 무언가를 시작했다고 해서 init자동으로 계속 실행되도록 시도하지는 않습니다. 당신은 에 있어야합니다 /etc/inittab.
• 런레벨을 종료할 때 /etc/rcX.d/K*영숫자 순서로 스크립트를 호출합니다. 여기서 X런레벨은 입니다. 종료 또는 다시 시작을 구현하는 한 가지 방법은 이러한 이벤트에 대한 실행 수준을 정의하고 마지막으로 실행된 작업을 halt또는 reboot명령으로 만드는 것입니다.
• 전원 이벤트 또는 Ctrl-Alt-Del과 같은 특정 이벤트에 대한 응답으로 실행 파일을 호출합니다.
• 소켓을 듣고 메시지를 받으면 런레벨을 변경합니다.

init따라서 원하는 경우 이를 기본 서비스 관리자로 사용할 수 있지만 이제 주요 작업은 getty사용자가 로그인하고 런레벨 전환을 시작할 수 있도록 이를 사용 가능하게 유지하는 것입니다.

시스템을 간단한 쉘로 설정하기 위해 init가 어떤 작업을 수행하는지 궁금합니다.

당신이 원하는 무엇이든. Debian에서는 모든 디렉토리에 완전히 사용자 정의하거나 제거할 수 있는 /etc/rcX.d스크립트에 대한 심볼릭 링크가 있습니다 . 순서는 각 스크립트 앞에 등을 /etc/init.d붙여서 설정됩니다.0001

단지 쉘을 생성하려는 경우 -b옵션 을 지정할 수도 있습니다 init(예: 커널 명령줄을 통해). init쉘을 종료하면 쉘 init이 종료되고, init쉘이 종료되면 커널이 패닉 상태가 됩니다.

init이 수행해야 하는 최소한의 작업은 최소한 하나의 다른 프로그램을 실행하고 절대 종료하지 않는 것입니다. init가 종료되면 시스템이 충돌합니다. 다른 프로그램을 실행하는 것조차 반드시 필요한 것은 아니지만, 그렇지 않은 경우 init는 시스템이 수행할 것으로 예상되는 모든 작업을 담당해야 합니다. 그렇지 않으면 별로 유용하지 않을 것입니다.

모듈식 "한 가지 일만 잘 수행" 원칙을 고수한다면 프로그램이 init프로세스를 시작해야 합니다.

프로세스 시작

성공적인 커널 압축 해제 후에 실행되어야 하며 시스템 작동에 필요한 모든 초기 프로세스(예: /etc/fstab에 있는 드라이브 마운트, 네트워크 인터페이스 시작 등)를 초기화하는 일을 담당합니다.

시작 및 종료 프로세스는 본질적으로 반대이기 때문에 init 프로그램은 일반적으로 종료 명령이 수신될 때 프로세스가 중지되도록 보장합니다.

프로세스 중지

이는 해당 프로세스의 매뉴얼 페이지에 따라 프로세스를 중지해야 함을 의미합니다(즉, 노골적으로 kill -9종료하려는 방식이 아니라 프로세스를 종료해야 함). 드라이브를 마운트 해제하고 마지막으로 최종 전원 끄기 명령을 실행해야 합니다. .

인용하다

다른 사람들이 이 작업을 수행한 방법에 대한 좋은 참고 자료는 다음을 확인하는 것입니다.Slackware의 /etc/rc.d 스크립트, 다음과 같이 이미 존재하는 간단한 초기화 시스템도 포함됩니다. 니넷(장관의 후임). 여기에는 프로세스 감독(프로세스가 종료되면 다시 시작됨을 의미함)이 있는데 이는 틀림없이 init의 작업은 아니지만 여전히 매우 기본적이고 이해하기 쉽습니다. 특히 작성자의 예제 스크립트를 사용하면 더욱 그렇습니다.