"Ubuntu Linux" 시스템에 대한 깊은 통찰력 - 우리는 이것을 볼 수 있습니까?
LINUX는 운영 체제가 아닌 커널이며 Debian, Fedora, Ubuntu와 같은 여러 배포판과 함께 제공됩니다. 강한> 등 그리고 더 많은. Mark Shuttleworth가 개발한 Ubuntu OS는 널리 알려져 있으며 많은 사람들이 널리 사용하고 있습니다. 또한 무료이며 오픈 소스이므로 개발에 기여하는 수천 명의 개발자가 기여하는 새 버전이 매년 출시됩니다. 그런데 어떻게 작동하나요? 모든 프로세스, 이벤트 목록이 작동하도록 하며 이러한 프로세스의 중요성은 무엇입니까?
이 기사는 매우 흥미롭고 Ubuntu OS의 내부에 대해 좀 더 깊이 있게 설명하고 초보자가 그 기능을 완전히 이해하는 데 도움이 될 것입니다.
시스템 배치
Linux에는 작동을 위한 프로세스가 있으며, 전원 관리, 부팅, 시스템 충돌 처리를 포함한 모든 시스템 서비스는 "/etc/init"에 이벤트를 설명하는 구성 파일이 있는 프로세스입니다. 실행을 중지할 해당 이벤트를 실행하고 시스템의 “/etc/” 디렉터리에 런타임 동작을 설명하는 다른 구성 파일도 유지하여 시스템을 만듭니다. 이벤트 중심의 것.
생성된 이벤트가 있는 경우 이를 포착하고 실행하기 위해 누군가가 있어야 합니까?? 분명히 컨트롤러는 프로세스 ID가 1인 모든 프로세스의 상위 프로세스로 존재하는 기본 프로세스입니다. 즉, init입니다. 이는 시스템 시작과 함께 시작되며 절대 멈추지 않는 프로세스입니다. init의 상위 프로세스가 없기 때문에 이 프로세스는 시스템 전원이 꺼진 후에만 종료됩니다.
6.10 이전의 Ubuntu 버전에는 “/etc/rcx.dsysvinit가 포함되어 있습니다. b> ” 시스템 시작 및 종료 시마다 디렉터리. 그러나 이후 upstart 시스템은 이전 스타일의 sysvinit 시스템을 대체했지만 여전히 이전 버전과의 호환성을 제공합니다.
최신 Ubuntu 버전에는 이러한 업스타트 시스템이 있지만 Ubuntu 6.10에서 발전한 이후 2014년 9월 4일 현재 버전인 1.13.2로 여러 개정판을 거쳤습니다. 최신 업스타트 시스템 2개의 init 프로세스가 있습니다. 하나는 시스템 프로세스용이고 다른 하나는 현재 로그인된 사용자 세션을 관리하고 사용자가 로그인할 때까지만 존재하며 x-session init라고도 합니다. .
전체 시스템은 시스템이 권력을 잡을 때부터 내려갈 때까지 조상-자식 관계로 구성된 계층적 시스템으로 구축되었습니다.
예: 두 초기화 프로세스 간의 작은 계층 관계는 다음과 같습니다. system init(1) -> 디스플레이 관리자(커널 공간) -> 디스플레이 관리자(사용자 공간) -> 사용자 초기화(또는 x-session 초기화).
system init에 의해 관리되는 프로세스의 구성 파일은 “/etc/init”에 있고 session init에 의해 관리되는 프로세스에 대한 구성 파일은 “/usr/share/upstart”에 있습니다(예: 1.12 이상의 최신 upstart 버전에 따라) 이러한 구성 파일은 이 문서에 설명된 프로세스에 대해 발굴된 많은 비밀의 핵심입니다.
계층 구조에 더 깊이 들어가기
Ubuntu는 두 가지 유형의 프로세스를 인식합니다.
- 단명 직업(또는 일하고 죽는 직업).
- 오래 사는 직업(또는 계속 일하면서 일하는 직업).
시스템에 만들어진 계층 구조는 구성 파일을 보면 이해할 수 있는 프로세스 간의 종속 관계로 인해 발생합니다. 먼저 시스템을 부팅하고 각 프로세스의 중요성을 이해하는 프로세스 간의 간단한 계층적 관계부터 시작하겠습니다.
부팅 계층
Init는 시스템 전원을 켤 때 시작하는 첫 번째 프로세스이며 절대 종료되지 않고 init가 종료되는 시간만 켜져 있으므로 작업 및 유지 작업으로 분류됩니다. 전원 끄기, 즉 초기화는 세션당 한 번만 종료되며 전원이 꺼지는 중입니다. 전원을 켜면 init는 시스템의 첫 번째 이벤트, 즉 시작 이벤트를 생성합니다. "/etc/init"의 각 구성 파일에는 프로세스를 시작하고 중지시키는 이벤트를 정의하는 두 줄이 있습니다. 해당 라인은 아래 그림에 강조표시되어 있습니다.
이는 failsafe-x 프로세스의 구성 파일이며 시작 및 중지 조건은 프로세스가 시작되는 이벤트를 설명합니다. init 프로세스에 의해 시작 이벤트가 생성되면 시작 조건이 시작인 프로세스가 병렬로 실행되며 이는 계층 구조만 정의하며 시작 시 실행되는 모든 프로세스는 init의 하위 프로세스입니다.
시작 시 시작되는 프로세스는 아래에 나열되어 있으며 모두 일과 죽음이 필요한 작업입니다.
1. 호스트 이름 – 이는 /etc/hostname 파일에 정의된 호스트 이름을 시스템에 알려주는 프로세스입니다.
2. kmod – /etc/modules 파일에서 커널 모듈, 즉 모든 드라이버를 로드합니다.
3. mountall – 이 프로세스는 많은 이벤트를 생성하며 주로 로컬 파일 시스템 및 원격 파일 시스템을 포함하여 부팅 시 모든 파일 시스템을 마운트하는 작업을 담당합니다.
/proc 파일도 바로 이 프로세스에 의해 마운트되며 모든 마운트 작업 후에 생성된 마지막 이벤트는 계층 구조를 더 진행하게 만드는 파일 시스템 이벤트입니다.
4. plymouth – 이 프로세스는 mountall을 시작할 때 실행되며 시스템 시작 시 아래와 같이 표시되는 검은색 화면을 표시하는 역할을 합니다.
5. plymouth-ready – 플리머스가 작동 중임을 나타냅니다.
다음은 기본 프로세스이며 udev-fallback-graphics 등과 같이 시작 시에도 실행되는 다른 프로세스입니다. 부팅 계층 구조로 돌아가면 간단히 말해서 다음 이벤트와 프로세스는 순서대로입니다.
1. 시작 이벤트 생성과 함께 init됩니다.
2. mountall 파일 시스템 마운트, 스플래시 화면을 표시하는 plymouth(mountall 시작과 함께) 및 커널 모듈 로드 kmod.
3. mountall에 의해 생성된 local-filesystem 이벤트로 인해 dbus가 실행됩니다. (Dbus는 다른 프로세스가 이 소켓에 메시지를 보내 서로 통신할 수 있도록 하는 소켓을 생성하고 수신자는 이 소켓의 메시지를 수신하고 해당 메시지를 필터링하는 시스템 전체 메시지 버스입니다.)
4. local-filesystem과 함께 시작된 dbus 및 local-filesystem 이벤트에서 실행되는 프로세스 네트워크로 인해 발생하는 static-network-up 이벤트로 인해 network-manager가 실행됩니다.
5. mountall에 의해 생성된 virtual-filesystem 이벤트로 인해 udev가 실행됩니다. (udev는 장치의 핫 플러그를 관리하고 /dev 디렉토리에 파일을 생성하고 관리하는 역할을 담당하는 Linux용 장치 관리자입니다.) udev는 mountall이 가상 마운트를 마친 /dev 디렉토리에 ram, rom 등의 파일을 생성합니다. -filesystems 및 /dev 디렉토리의 마운트를 나타내는 virtual-filesystem 이벤트를 생성했습니다.
6. udev를 사용하면 upstart-udev-bridge가 실행되어 로컬 네트워크가 작동 중임을 나타냅니다. 그런 다음 mountall이 마지막 파일 시스템 마운트를 완료하고 파일 시스템 이벤트를 생성한 후입니다.
7. static-network-up 이벤트와 함께 filesystem 이벤트가 발생하면 rc-sysinit 작업이 실행됩니다. 여기에는 이전 sysvinit과 신생 기업 간의 하위 호환성이 있습니다…
9. rc-sysinit는 시스템 런레벨을 알려주는 telinit 명령을 실행합니다.
10. 런레벨을 얻은 후 init는 'S' 또는 'K'로 시작하는 스크립트를 실행합니다('S'가 있는 작업 시작). /etc/rcX.d 디렉토리에서 이름 시작 부분에 'K'가 있는 항목을 종료합니다. 여기서 'X'는 현재 런레벨입니다. .
이 작은 이벤트 세트로 인해 시스템 전원을 켤 때마다 시스템이 시작됩니다. 그리고 프로세스를 트리거하는 이 이벤트는 계층 구조 생성을 담당하는 유일한 것입니다.
이제 위의 또 다른 추가 기능이 이벤트의 원인입니다. 어떤 프로세스가 어떤 이벤트를 발생시키는지 아래 줄에 표시된 것과 같이 프로세스의 동일한 구성 파일에도 지정됩니다.
위는 프로세스 mountall의 구성 파일 섹션입니다. 이는 그것이 방출하는 이벤트를 보여줍니다. 이벤트 이름은 '이벤트' 뒤에 오는 이름입니다. 이벤트는 위와 같이 구성 파일에 정의된 것일 수도 있고 'starting', 'started', 'stopping' 또는 'stopped'라는 접두사가 붙은 프로세스 이름일 수도 있습니다.
따라서 여기서는 두 가지 용어를 정의합니다.
- 이벤트 생성기: 구성 파일에 'emits xxx' 줄이 있는 것입니다. 여기서 xxx는 소유하거나 생성하는 이벤트의 이름입니다.
- 이벤트 캐처: 시작 또는 중지 조건이 xxx인 이벤트 발생기 중 하나가 생성한 이벤트에서 시작 또는 중지되는 이벤트 캐처입니다.
따라서 계층 구조는 프로세스 간 종속성을 따릅니다.
Event generator (parent) -> Event catcher (child)
계층 구조에 복잡성 추가
지금까지 간단한 부팅 메커니즘을 통해 이벤트 트리거 메커니즘에 의해 프로세스 간의 상위-하위 종속성 계층이 어떻게 배치되는지 이해해야 합니다.
이제 이 계층 구조는 자식 하나에 부모 하나만 있는 일대일 관계가 아닙니다. 이 계층 구조에서는 하나의 자식에 대해 하나 이상의 부모가 있거나 하나 이상의 자식의 부모가 되는 하나의 프로세스가 있을 수 있습니다. 이것이 어떻게 이루어 집니까?? 대답은 구성 파일 자체에 있습니다.
이 줄은 프로세스에서 가져온 것입니다. 네트워킹이며 여기서 시작 조건은 local-filesystems, udevtrigger, container<와 같은 많은 이벤트로 구성되어 너무 복잡해 보입니다., 런레벨, 네트워킹.
Local-filesystems는 mountall에 의해 생성되고, udevtrigger는 작업 이름이고, 컨테이너 이벤트는 컨테이너 감지에 의해 생성되고, runlevel 이벤트는 rc-sysinit에 의해 생성되며, 네트워킹은 다시 작업입니다.
따라서 계층 구조에서 프로세스 네트워킹은 기능을 계속할 수 없기 때문에 mountall, udevtrigger 및 Container-Detect의 하위입니다(프로세스 기능은 프로세스 구성 파일의 script 또는 exec 섹션에 정의된 모든 라인입니다). 위 프로세스가 이벤트를 생성할 때까지
마찬가지로, 한 프로세스에서 생성된 이벤트가 여러 프로세스에 의해 캐시된 경우 하나의 프로세스가 여러 프로세스의 상위가 될 수 있습니다.
직업 유형 구별
이전에 정의한 대로, 우리는 단기(또는 일하고 죽는) 직업 또는 장기(또는 머물고 일하는) 직업을 가질 수 있지만 두 직업을 구별하는 방법은 무엇입니까? 그들을??
구성 파일에 '시작' 및 '중지' 조건이 모두 지정되어 있고 해당 파일에 '작업'이라는 단어가 있는 작업 구성 파일은 생성된 이벤트에서 시작하여 해당 스크립트나 실행 섹션을 실행하고(실행하는 동안 이를 유발한 이벤트를 차단함) 차단한 이벤트를 해제한 후 종료되는 작업 및 종료 작업입니다. .
구성 파일에 '중지' 조건이 없는 작업은 오래 지속되거나 머무르며 작업하는 작업이며 절대 죽지 않습니다. 이제 체류 및 근무 직업은 다음과 같이 더 분류될 수 있습니다.
- 리스폰 조건이 없고 루트 사용자에 의해 종료될 수 있는 것입니다.
- 구성 파일에 리스폰 조건이 있어서 작업이 완료되지 않으면 종료된 후 다시 시작됩니다.
결론
따라서 LINUX의 각 프로세스는 일부 프로세스에 종속되고 일부 프로세스가 이에 종속되며 이 관계는 다수에 많으며 프로세스의 다른 세부 사항과 함께 upstart 시스템으로 지정됩니다.