![추가 읽기](https://linux55.com/image/176194/%EC%B6%94%EA%B0%80%20%EC%9D%BD%EA%B8%B0.png)
init에 대한 나의 지식은 제한되어 있습니다. 내가 아는 것은 init가 커널 부팅 후 시작되는 첫 번째 프로세스이며 프로세스 ID 1이 할당된다는 것뿐입니다.
최근에 그런 일을 겪었을 때GNU 셰퍼드, 다음 문장을 발견했습니다.
SysV-init(또는 다른 init)의 서비스 관리 기능을 강력하고 아름답게 대체합니다.의존성 기반 시스템편리한 인터페이스를 가지고 있습니다.
그렇다면 여기서 종속성 기반 시스템이 무엇을 의미하는지 알고 싶습니다. 이것이 널리 사용되는 SysV 또는 Sysmted init 시스템과 구별되는 기능입니까?
답변1
종속성 기반 초기화 시스템은 서비스 초기화 순서가 서비스 내에서 또는 서비스와 함께 제공되는 종속성 정보를 기반으로 하는 시스템입니다. 이는 순서가 정적으로 결정되는 init 시스템과 대조됩니다(질문에 포함된 다이어그램에 표시된 것처럼 종종 사전식 순서에 의존함).
일부 시스템에서는 두 가지 접근 방식을 혼합할 수 있습니다. 예를 들어 사용되는 Debian 시스템에서 sysvinit
종속성 기반 계층은 초기화 sysvinit
스크립트의 LSB 헤더를 사용하여 초기화 순서를 계산하고 /etc/rc?.d/
적절하게 명명된 기호 링크를 통해 저장합니다.
답변2
많은 사람들이 이것을 오해하고 있습니다. 여기에 있는 답변 중 일부는 잘못되었습니다.
먼저 몇 가지 잘못된 이름을 정리하겠습니다.
init
프로세스 #1로 실행되는 프로그램과 다른 프로세스로 실행되는 프로그램의 차이점은rc
Unix의 첫 번째 버전으로 거슬러 올라갑니다. 당신이 논의한 많은 것프로세스 #1에서는 수행되지 않음대부분의 서비스/시스템 관리 소프트웨어에서 Upstart 및 systemd는예외규칙보다는.init
"sysvinit"은 AT&T Unix System 5+ 가 아닙니다rc
. 이것은 원래 Miquel van Smoorenburg가 Minix용으로 작성한 클론init
이자 시스템입니다rc
. 아이러니하게도 AT&T Unix System 5가 나온 지 몇 년 후입니다.대부분 폐지시스템을 서비스 액세스 시설이라는 것으로 대체합니다.
당신이 물었어요서비스 관리, 위에서 언급한 서비스 액세스 기능(SAF), AIX 시스템 리소스 컨트롤러(SRC), Solaris 서비스 관리 기능(SMF), systemd, Upstart, daemontools, daemontools-encore, runit, nosh 도구 세트 AT&T Unix의 서비스 관리 작업, s6 및 기타 다양한 도구 세트. SAF와 SRC가 등장하기 전의 원래 AT&T Unix System 5는 rc
서비스 프로세스를 직접 분기했을 뿐 실제로는 이를 수행하지 않았습니다.관리하다그 후 그들은.
Linux의 van Smoorenburg(Minix 출신)는 rc
여전히 이 작업을 수행합니다. 또한 처음에는 수동보다는 임시 서비스 시작/종료 순서에 의존했습니다. 원래의 거대한 모노글리프는 rc
1970년대와 1980년대 초반에 여러 번의 돌연변이를 겪었고 여전히 여기저기서 화석을 찾을 수 있으며(예를 들어 rc.local
) van Smulenberg가 1990년대에 그것을 복제했을 때 rc
그것은 세트가 되었습니다.끼워 넣다/etc/
하위 디렉토리 및 일부 심볼릭 링크 필드( 의 다른 하위 디렉토리 ) 에 있는 스크립트는 /etc/
이러한 스크립트가 전체 작업을 수행하는 순서를 나타냅니다 rc
. 심볼릭 링크 팜은 다양한 rc
스크립트에 0부터 99까지 우선 순위가 할당되는 우선 순위 체계를 기반으로 합니다 . (1990년대 후반에 심볼릭 링크 팜을 위한 대체 메커니즘인 file-rc가 있었지만 이것도 우선 순위 시스템을 사용했습니다.) 이는 우선 순위 선택에 대한 보편적인 관례가 없었고 "두 소프트웨어가 1위가 되라”는 문제이다. (아이러니하게도 보시다시피화석 방식으로 일을 하는 사람들은 이 WWW 사이트에서 관련 질문 중 하나를 묻습니다.바로 어제.)
종속성 기반 서비스 관리더 잘하려고 노력하십시오. 서비스 정의는 어떤 형태로든 각 서비스가 수행하는 작업을 나열합니다.에 따라그리고에 상대적이어야 한다시작하고 종료할 때. '처음'과 '마지막'은 없지만,앞으로그리고뒤쪽에, 또한필요그리고충돌하다.
이는 21세기 대부분 동안 rc
Linux 및 BSD의 레거시 시스템에 존재해 왔습니다.
- Mewburn
rc
과 OpenRC(두 가지 모두 21세기의 발명품)는 이전 시스템에서 학습했으며rc
처음부터 서로 다른 스크립트 간의 상호 의존성을 표현하는 방법을 채택했습니다. Mewburn에서는rc
다양한 스크립트(예: , , 및 )의 주석 시스템이 서비스 간의 상호 의존성을 표현하고 이를 기반으로 실행 파일이라는 프로그램이 각 부팅/종료 시작 시 작업을 실행할 순서를 계산합니다.rc
REQUIRE
PROVIDE
BEFORE
rcorder
rc
van Smoorenburg 는 데비안 사람들로부터 .insserv
서비스 간의 상호 의존성은 다양한 스크립트에 주석으로 포함된 기존 "LSB 헤더" 시스템을 통해 표현되며 , 소프트웨어 설치/제거 시 종속성을 반영하기 위해rc
우선 순위가 심볼릭 링크로 다시 작성됩니다 .insserv
데비안과 그 파생물 중 일부는 2000년대 후반에 이것을 많이 채택했습니다. 바라보다데비안 위키더 알아보기.
rc
또한 처음부터 Solaris SMF에서 systemd에 이르기까지 많은 비서비스 관리자에서 일류 메커니즘으로 존재해 왔습니다. 주목할만한 예외로는 Upstart, daemontools(및 daemontools-encore, perp 및 runit) 및 (몇 년 전) s6이 있습니다.
daemontools, runit 등 이들 모두는 처음에는 문제를 해결하기 위해 "거대한 천둥 떼" 접근 방식을 취했고, 모두 작동할 때까지 계속해서 서비스를 시작하고 다시 시작했습니다. 일부 사람들은 서비스를 일시 중지하고 다른 일이 발생할 때까지 기본 서비스 프로그램을 호출하지 않는 등의 트릭을 사용하여 이를 약간 조정하지만 기본 아이디어는 여전히전체 디렉토리의 모든 항목을 "스캔"합니다.한꺼번에 시작됐어요.
나는 기본적인 서비스 관리 위에 약간의 계층을 추가하면 더 나은 일이 이루어질 수 있다고 오랫동안 믿어왔고 궁극적으로 다음과 같이 증명했습니다.이를 수행하기 위한 특정 도구 세트, 실제 서비스 관리자에서 시작 "스캔" 로직을 가져와 별도의 프로그램으로 이동하고 기본 daemontools 서비스/감독 디렉토리 구조를 중심으로 서비스 번들 상호 의존성 시스템을 구축합니다. Laurent Bercot도 s6의 추가 기능으로 동일한 효과를 보여주었습니다.s6-rc. OpenRC조차도 rc
스크립트가 상호 의존성을 표현하고 외부 서비스 관리자(예: s6)를 사용할 수 있기 때문에 이를 입증합니다.
아이러니하게도 Upstart는 실제로 (2005년에) 2010년대 일부 사람들의 아이디어로 고안되었습니다.새로운서비스가 관리되는 방식,바꾸다종속성 기반 서비스 관리이벤트 기반서비스 관리, 서비스 시작발생한 사건결과적으로라기보다는순서가 지정된 종속성 세트 계산. 이 개념이 궁극적으로 거부된 이유를 논의하는 것은 이 답변의 범위를 벗어납니다.돌아가다그러나 2010년대 초반에는 종속성 기반 서비스 관리가정상. 신생 개발자들은 그것이 구식이라고 생각합니다. van Smoorenburg는 rc
Debian 작업을 통해 이를 얻었지만 Fedora와 SUSE는 실제로 Debian에서 이를 상속받지 않았습니다. Mewburn rc
과 OpenRC는 처음부터 이를 갖고 있었습니다. systemd는 곧 발명될 것입니다. 솔라리스, 일루모스 등 SMF와 함께 사용됩니다. 등.
runit 및 Upstart를 제외하면 이는 눈에 띄는 기능이 아닙니다. 이것은 표준이었고 현재입니다. 이것은 GNU Shepherd 초기에도 다른 사람들이 해왔거나 하고 있는 일입니다. 현재 GNU Shepherd라고 불리는 GNU dmd는 2003년에 개발되었습니다. Debian은 2002년에 스위치를 시작했습니다 insserv
. Richard Gooch는 need
2002년에 이에 대해 썼습니다. Mewburn은 rc
2000년에 발명되었으며 해당 주제에 대한 Luke Mewburn의 원본 논문에서는 파일 이름에 인코딩된 것보다 우선 순위를 사용하는 방법을 설명합니다. 레벨 시스템은 종속성을 표현하는 데 더 좋습니다. 디자인 특징으로.
추가 읽기
- 조나단 데보인 폴라드(2018).
/etc/rc.local
그것은 과거의 일입니다.. 일반적인 답변. - 조나단 데보인 폴라드(2015).시스템 5의 알려진 문제
rc
. 일반적인 답변. - 조나단 데보인 폴라드(2018). Unix 서비스 액세스 도구. 일반적인 답변.
- 가상현실(2015-09-05).현대 초기화 시스템의 역사(1992-2015). darknedgy.net.
답변3
이것이 널리 사용되는 SysV 또는 Sysmted init 시스템과 구별되는 기능입니까?
글쎄, 아니부터체계, “잘 설계된 트랜잭션을 구현합니다.의존성 기반서비스 제어 논리”(강조).
레나르트 포터링의 말을 인용하겠습니다.systemd의 기본 원리여기:
이러한 모든 단위는 상호 종속성(긍정적 및 부정적, 즉 "필요" 및 "충돌")을 가질 수 있습니다. 장치는 서비스에 대한 종속성을 가질 수 있습니다. 즉, 장치를 사용할 수 있게 되자마자 특정 서비스가 시작된다는 의미입니다. 마운트에는 마운트된 장치에 대한 암시적 종속성이 있습니다. 또한 마운트는 앞에 붙은 마운트에 대한 암시적 종속성을 얻습니다(즉, /home/lennart를 마운트하면 암시적으로 /home 마운트에 종속성이 추가됩니다).
예전 sysv 시절에는 시스템 서비스 간의 종속성을 표현하는 최고의 방법이 없었습니다. 스크립트 순서 사용, 헤더 제출 등의 측면에서 하드와이어되어 있지만 이러한 시스템은 본질적으로 취약합니다. 이로 인해 올바르게 주문하기가 특히 어렵습니다. 예를 들어 이 서비스에서는 이 네트워크 인터페이스와 이 마운트 지점이 작동해야 하지만 해당 마운트 지점에는 다른 장치가 작동되어야 합니다. /etc/rcX.D/
스크립트에서 숫자 수동 주문 접두어를 사용하는 것을 고려하십시오. .
적절한 시스템을 사용하여 유닛 간의 종속성을 표현함으로써 init 시스템이 서비스가 서로 및 시스템과 어떻게 관련되는지에 대한 모든 정보를 갖고 있기 때문에 올바른 순서를 파악할 수 있습니다.
대조를 위해 종속성을 사용하는 대신 이벤트에 직접 의존하는 Upstart를 고려하십시오.
Upstart는 다음 이벤트를 통해 서비스 직렬화를 수행합니다. syslog-started 이벤트가 트리거되면 이제 Syslog를 사용할 수 있으므로 D-Bus를 시작하라는 표시로 사용됩니다. 그런 다음 dbus-started가 트리거되면 이제 D-Bus 등을 사용할 수 있으므로 NetworkManager가 시작됩니다.
이러한 방식으로 관리자나 개발자가 이해하는 실제 논리적 종속성 트리는 이벤트 및 작업 규칙으로 변환되고 인코딩된다고 말할 수 있습니다. 관리자/개발자가 이해하는 각 논리적 "a는 b가 필요합니다" 규칙은 "시작"이 됩니다. b가 시작하면 a를 중지합니다." + "b가 중지하면 a를 중지합니다."
답변4
이러한 맥락에서 "종속성 기반"이란 서비스가 제공되는 순서를 결정하기 위해 다른 요인에 의존하는 대신 일반적으로 런타임을 통해 다른 서비스에서 제공하는 기능이 실제로 필요한 서비스를 확인하고 일반적으로 사용자 개입이 전혀 없음을 의미합니다. start9(예: 어휘 순서) 파일 이름).
init.d
이는 systemd가 출현하기 전에 대부분의 Linux 배포판이 사용했던 원래 SVR4 초기화 배열 및 일부 이전 BSD 방법과 대조됩니다 rc.d
. 이 방법에서는 모두 사용자/관리자가 서비스가 시작된 순서를 수동으로 제공해야 했습니다. 파일 이름이나 변수를 수동으로 설정하거나 도구를 실행하여 스크립트에 포함된 메타데이터를 검색합니다.
현재 활발히 사용되고 있는 종속성 및 서비스 감독 기반 시스템의 다른 예 init
는 다음과 같습니다.
- OpenRC: Alpine과 Gentoo에서 사용됩니다. 종속성 정보를 얻으려면 init 스크립트 자체에서 특수 함수 정의와 매크로를 사용하십시오(
lvmetad
LVM 구성에서 활성화된 경우에만 LVM을 실행하면 되는 것과 같이 서비스 간의 조건부 종속성을 표현할 수 있으므로 이는 실제로 매우 강력합니다). 일반" 종속성(즉, 실행 중인 syslog 데몬이 필요하지만 어떤 데몬이 실행 중인지는 고려하지 않음). - Monit: 서비스 감독자,
init
경우에 따라 대체합니다. 런타임 종속성 계산은 모니터링하는 엔터티(이 경우 서비스가 아닌 "엔티티")에 대해 정의된 종속성을 기반으로 합니다. 네트워크의 다른 곳에서 외부 서비스나 시스템 콘텐츠의 파일 및 디렉터리를 모니터링하고 의존할 수 있기 때문입니다. 서비스). init
Upstart: Ubuntu의 레거시 대체품입니다. 종속성 추적을 직접 수행하는 대신 Upstart를 사용하면 서비스가 이벤트를 기반으로 상태 변경을 트리거할 수 있으며, 이는 효율적인 종속성 기반 서비스 시작 시퀀스를 제공하는 데 사용됩니다.- Systemd: 종속성 기반 순서 지정의 현재 예입니다(종종
init
팬들이 이러한 시스템이 최초라고 잘못 주장함). 종속성 계산은 런타임 시 수행되며 경우에 따라 엄격한 종속성 추적의 필요성을 실제로 완화할 수 있는 기능을 제공합니다.