리눅스 배포판을 만들고 있는데 이제 init 프로그램이 필요합니다. 나는 c로 정말 잘 코딩 할 수 있고 리눅스에 대해 꽤 많이 알고 있습니다 (4 년 동안 개발을 위해 아치 리눅스를 사용해 왔습니다). 그래서 C로 자신의 기본 init 스크립트를 작성해야한다고 생각했습니다. 단순한 쉘을 위해 시스템을 설정하기 위해 init가 수행하는 작업은 무엇입니까? ( "init의 기능은 무엇입니까?"라고 물으면 init의 의미와 용도를 알 수 있습니다.

코드가 필요하지 않으며 기본 명령 이 필요 하지 않지만 실행 순서 가 필요합니다.

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

리눅스 세계에 영향을 미치는 근시가 있습니다. 사람들은 자신들이 "시스템 5 init" 라는 것을 사용한다고 생각합니다. 이것이 전통적이며 시작하기 가장 좋은 곳입니다. 사실도 마찬가지입니다.

전통은 실제로 그러한 사람들이 처음부터 그렇게 말하는 것이 아닙니다. System 5 init와 System 5 rc는 AT & T UNIX System 5에 해당합니다. AT & T UNIX는 Linux-Mandrake의 첫 번째 버전 이후와 마찬가지로 첫 번째 UNIX와 거의 거리가 멀었습니다.

1st Edition UNIX에만 init있습니다. 가지고 있지 않았습니다 rc. 제 1 회 판 어셈블리 언어 init( 그 코드가 되었습니다 복원 워렌 투미 등으로 이용 가능. ) 직접 양산 및 12 개 리스폰 getty과정에서 3 개 배선에 파일 시스템을 마운트 테이블에 내장하고, 직접의 홈 디렉토리에서 프로그램을 실행 사용자 이름이 mel. getty테이블은 프로그램 이미지에 직접도했다.

유닉스 시스템 5 이후 10 년이 지나서 "전통적인"리눅스 초기화 시스템이 등장했다. 1992 년 Miquel van Smoorenburg (리-)는 Linux init+ rc및 관련 도구를 작성했는데 init, 실제로 UNIX System 5의 소프트웨어가 아니더라도 사람들은 이제 "System 5 "라고합니다. init).

System 5 init/ rc는 시작하기 가장 좋은 장소가 아니며, 알고 있어야 할 것의 절반을 포함하지 않는 systemd에 대한 지식을 추가하더라도. init 시스템 디자인 영역 (Linux 및 BSD 용)에서 지난 20 년 동안 만 일한 많은 작업이있었습니다. 모든 종류의 엔지니어링 결정이 논의, 결정, 설계, 구현 및 실행되었습니다. 상업용 Unices도 많은 일을했습니다.

공부하고 배우는 기존 시스템

다음은이 두 가지 이외 의 주요 init 시스템 중 일부 와 그 중 몇 가지 (몇 가지) 두드러진 점에 대한 불완전한 목록입니다 .

• Joachim Nilsson의 finit 는보다 사람이 읽을 수있는 구성 파일을 사용하는 길을갔습니다.
• 펠릭스 폰 레이트 너의 MINIT는 것들 사이 / 정지 종속성을 파일 시스템 - 인 - 더 - 데이터베이스 구성 시스템, 작은 메모리 풋 프린트에 들어갑니다, 그리고 시작 init이 시작됩니다.
• Gerrit Pape의 runit 은 방금 4 개의 쉘 스크립트 접근 방식으로 설명한 바를 따릅니다 .
• InitNG 는 하위 프로세스에 대한 더 많은 설정을로드 할 수있는 종속성, 명명 된 대상, 여러 구성 파일 및보다 유연한 구성 구문을 갖기를 목표로했습니다.
• upstart 는 시스템을 서비스 및 상호 의존성으로 모델링하는 것이 아니라 이벤트 및 작업으로 트리거되는 시스템을 완전히 재 설계하여 완전히 재 설계했습니다.
• 의 디자인 요기는 (심지어 포함한에서 서비스 관리의 모든 밀어 포함 getty별도의 서비스 매니저에 산란하고 좀비 수확을), 및 단지 운영 체제 별 "API"장치 / 심볼릭 링크 / 디렉토리 및 시스템 이벤트를 처리.
• sinit 은 매우 간단한 init입니다. 그것은 실행 /bin/rc.init그의 작업은 당신이 같은 것을 사용할 수 있습니다이를 위해 등, 파일 시스템 마운트, 프로그램을 시작하는 것입니다 minirc을 .

또한, 약 10 년 전, 데몬툴 사용자와 svscan프로세스 # 1로 사용하는 데 대한 토론이 있었는데 , 이는 Paul Jarc의 svscan을 프로세스 1 연구로 , Gerrit Pape의 아이디어를 , Laurent Bercot의 svscan을 프로세스 1 로하 는 프로젝트로 이어졌습니다 .

어느 프로세스 # 1 프로그램이하는지 알려줍니다.

프로세스 # 1 프로그램의 기능

어떤 프로세스 # 1이 "추정"되어야하는지에 대한 개념은 본질 상 주관적이다. 의미있는 객관적인 디자인 기준은 프로세스 # 1 이 최소로해야 할 일입니다. 커널에는 몇 가지 요구 사항이 있습니다. 그리고 항상 다양한 종류의 운영 체제 별 작업이 필요합니다. 전통적으로 프로세스 # 1이 수행 한 작업에 관해서는, 우리는 최소한도 아니고 실제로도 본 적이 없습니다.

다양한 운영 체제 커널 및 기타 프로그램이 프로세스 # 1에서 요구하는 것 중 하나는 단순히 벗어날 수없는 것입니다.

사람들은 fork()일을하고 고아 프로세스의 부모 역할 을 하는 것이 프로세스 # 1의 주요 기능 이라고 말할 것입니다 . 아이러니하게도, 이것은 사실이 아닙니다. 고아 프로세스 처리 ( https://unix.stackexchange.com/a/177361/5132에 설명 된 최신 Linux 커널 사용 )는 프로세스 # 1에서 다른 프로세스 (예 : 전담 서비스 관리자 . 이들은 모두 프로세스 # 1에서 실행되는 서비스 관리자입니다.

• IBM AIX srcmstr프로그램, 시스템 자원 제어기
• Gerrit Pape의 runsvdirrunit
• 다니엘 J. 번스타인의 svscan데몬 툴즈에서 아담 샘슨의 svscan에서 freedt , 브루스 귄터의 svscan데몬 툴즈 - 앙코르에서, 그리고 로랑 Bercot의 s6-svscan에서 S6
• 웨인 마샬의 perpd범인에서
• Solaris 10의 서비스 관리 기능
• service-manager요기에서

마찬가지로 https://superuser.com/a/888936/38062 에서 설명한 것처럼 전체 /dev/initctl아이디어는 프로세스 # 1 근처에있을 필요는 없습니다. 아이러니하게도, 프로세스 # 1에서 벗어날 수 있음을 보여주는 중앙 집중식 시스템입니다.

반대로위한 필수 일이 init, 그 사람들은 일반적으로 자신의 오프 - 더 - 최고의 - 헤드 디자인에 잊지 같은 핸들링과 같은 것들 SIGINT, SIGPWR, SIGWINCH, 등 커널에서 전송하고 전송 된 다양한 시스템 상태 변경 요청을 제정은 # 1을 처리하기위한 특정 신호가 특정 것을 의미한다는 것을 "알고있는"프로그램으로부터. (예 : https://unix.stackexchange.com/a/196471/5132에 설명 된대로 BSD 툴셋 SIGUSR1은 특정 의미 를 갖는 "알고 있습니다."

"API"파일 시스템 마운트 또는 파일 시스템 캐시 플러시 와 같이 일회성 초기화 및 마무리 작업도 수행 할 수 없거나 수행하지 못하는 경우가 많습니다 .

"API"파일 시스템을 다루는 기본 사항은 initrom 1st Edition UNIX 의 작업과 거의 다릅니다 . 하나는 프로그램에 하드 와이어 된 정보 목록이 있고 하나는 목록 mount()의 모든 항목입니다. 이 메커니즘 init은 nosh를 통해 BSD (sic!)와 같은 다양한 시스템 system-manager에서 systemd로 찾을 수 있습니다.

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

살펴본 바와 같이, init=/bin/sh"API"파일 시스템이 마운트되지 않고, 한 유형 exit( https://unix.stackexchange.com/a/195978/5132 )에서 캐시 플러시없이 비정상적으로 충돌 하며 일반적으로 그대로 둡니다. (수퍼) 사용자에게 시스템을 최소한으로 사용할 수있게하는 작업을 수동으로 수행합니다.

프로세스 # 1 프로그램에서 실제로 수행 할 수있는 작업이 무엇인지 확인하고 명시된 설계 목표를 달성 할 수있는 좋은 방법을 선택하려면 Gerrit Pape의 runit, Felix von의 작업에서 겹치는 부분을 보는 것이 가장 좋습니다. Leitner 's minit와 system-managernosh 패키지 의 프로그램. 전자의 두 가지는 미니멀리스트하려는 두 가지 시도를 보여 주지만 여전히 피할 수없는 것들을 처리합니다.

후자는 system-manager프로그램에 대한 광범위한 수동 입력에 유용하며 , 이는 "API"파일 시스템이 마운트되는 대상, 초기화 작업이 실행되는 신호 및 처리되는 신호를 정확하게 설명합니다. 시스템에 있음을 디자인하여 시스템 관리자가 단지 다른 세 가지 (서비스 관리자, 동반 로거 및 상태 변경을 실행할 수있는 프로그램) 만 처리 # 1의 피할 수없는을 산란.

데비안 시스템 V init (다른 변형 및 변형이 있음)는 다음을 수행합니다.

• 런레벨에 들어가면 스크립트 /etc/rcX.d/S*는 영숫자 순서로 스크립트를 호출합니다 X. 런레벨은 어디 입니까? 이 스크립트는 런레벨을 설정해야합니다. 일반적인 설정은 데몬을 시작하고 해당 실행 수준에 대한 설정 작업을 수행합니다. 이것은 런레벨에 들어갈 때 한 번만하는 일입니다.
• 실행 레벨에있는 /etc/inittab동안 해당 실행 레벨 동안 활성화되어야 하는 데 나열된 데몬을 시작 합니다. 해당 데몬의 실행이 중지되면 다시 시작됩니다. 로 관리하려는 데몬을 가질 수는 있지만 init최소한 몇 개만 getty있으면 로그인 할 수 있습니다. getty로그인이 완료되면 종료 한 다음 init다시 시작하여 새로운 로그인 프롬프트를 제공합니다.
  
  • 데몬이 너무 짧은 시간에 너무 여러 번 다시 시작되면 잠시 동안 다시 시작을 중지합니다.
  • 실행 레벨에 들어갈 때 킥오프 스크립트에 의해 무언가가 시작되었다고해서 init자동으로 실행 상태를 유지 하지는 않습니다 . 에서 별도로 지정해야합니다 /etc/inittab.
• 런레벨을 종료하면 스크립트 /etc/rcX.d/K*가 영숫자 순서로 X실행 되며 여기서 런레벨은 어디 입니까? 종료 또는 재부팅을 구현하는 방법은 해당 이벤트에 대한 실행 수준을 정의하고 마지막 작업이 halt또는 reboot명령을 실행하도록하는 것 입니다.
• 전원 이벤트 또는 Ctrl-Alt-Del과 같은 특정 이벤트에 대한 응답으로 실행 파일을 호출합니다.
• 소켓에서 수신 대기하며 특정 메시지를 수신하면 실행 레벨이 변경됩니다.

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

시스템을 간단한 쉘로 설정하기 위해 init가 수행하는 작업은 무엇입니까?

당신이 원하는대로. 데비안에서 각 /etc/rcX.d디렉토리에서 스크립트에 대한 심볼릭 링크 /etc/init.d와는 완전히 사용자 정의하거나 그 스크립트를 제거 할 수 있습니다. 순서는 각 스크립트를 이전에 의해 설립 00, 01등

쉘을 스폰 하고자한다면 (커널 명령 행을 통해) -b옵션을 지정할 수도 있습니다 . 당신이 쉘, 종료하면 다이 때 다이를, 커널은 멎어 버립니다.initinitinitinit

초기화해야 할 최소한의 최소한 하나 이상의 다른 프로그램을 실행하고 종료하지 마십시오. init가 종료되면 시스템이 중단됩니다. 다른 프로그램을 실행하는 것조차 반드시 필요한 것은 아니지만, 그렇게하지 않으면 시스템이 수행해야 할 모든 일을 수행해야 할 책임이 있거나 그렇게 유용하지 않을 것입니다.

init 당신이 원하는대로 할 수 있습니다

init는 부팅 프로세스가 끝날 때 Linux 커널이 호출하는 임의의 실행 파일입니다 (이러한 실행 파일은 유일합니다).

일반적으로 ELF 실행 파일로 구현되지만 다음과 같은 쉘 스크립트 일 수도 있습니다 chmod +x. Init as a shell script

sysemd와 같은 일반적인 구현 /etc/initrc은 시스템의 다양한 측면을 구현하기 위해 구성 파일을 읽은 다음 해당 구성을 기반으로 여러 사용자 프로세스를 분기합니다.

그러나 이것은 구현에 따라 다르므로 특정 구현을 지정하지 않으면 질문에 답할 수 없습니다. 예를 들어, 나는 교육 목적으로 init단순히 rebootsyscall 을 수행하는 프로세스를 가지고 놀고 있습니다.

Linux 커널 /init은 기본적으로 경로에서 실행 파일을 찾기 만하지만 init=Linux 커널 명령 행 매개 변수 로 대체 할 수 있습니다 .

init이 문제를 해결하는 좋은 방법 중 하나 는 QEMU를 사용하는 것입니다. QEMU 명령 줄에서 커널 명령 줄 매개 변수를 -append옵션 을 사용하여 QEMU에 전달할 수 있기 때문입니다.

다음은 완벽하게 자동화 된 Buildroot + QEMU 설정으로 , 문제를 이해하기 위해 자신의 init로 매우 쉽게 플레이 할 수 있습니다.

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

프로세스 시작

커널이 성공적으로 압축 해제되면 시스템이 작동하는 데 필요한 모든 초기 프로세스 (예 : / etc / fstab에있는 드라이브 마운트, 네트워크 인터페이스 가져 오기 및 곧).

부팅 및 종료 프로세스는 본질적으로 서로 반대이므로 init 프로그램은 종료 명령시 프로세스가 중지되도록하는 것이 일반적입니다.

프로세스 중지

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

참고 문헌

이것이 다른 사람들에 의해 수행되는 방법에 대한 좋은 참고 문헌은 Slackware의 /etc/rc.d 스크립트 와 ninit ( 최후의 미니언 )와 같이 이미 존재하는 간단한 init 시스템을 보는 것 입니다. 그것은 프로세스 감독 (프로세스가 죽으면 다시 시작된다는 것을 의미)을 가지고 있습니다. 이것은 아마도 초기 작업이 아니지만 특히 저자의 샘플 스크립트를 통해 이해하는 것은 매우 기본적이고 간단합니다.