CentOS 7의 시스템화된 관리 시스템에 대한 심층 분석

CentOS 시스템 시작 프로세스:

POST --> 부트로더 --> 커널 + initramfs(initrd) --> /sbin/init

innit 프로그램:

CentOS 5: SysV 초기화

CetnOS 6: 업스타트

CentOS 7: 시스템화

시스템의 새로운 기능:

시스템 Sys V init 및 LSB init 스크립트 호환

시스템 부팅 시 서비스의 병렬 시작 달성 소켓/D-Bus 활성화 및 기타 기술을 사용하여 서비스 시작 시스템 시작 시간을 줄이기 위해 systemd의 목표는 가능한 한 적은 수의 프로세스를 시작하는 것입니다. 가능한 한 많은 프로세스를 병렬화하려면

주문형 프로세스 활성화 Systemd는 실제로 요청될 때만 서비스를 시작하여 주문형으로 시작하는 기능을 제공할 수 있습니다. 서비스가 종료되면 systemd는 서비스를 종료하고 다음에 필요할 때 다시 시작할 수 있습니다.

시스템 스냅샷 및 복원 기능

마운트 지점 및 자동 마운트 지점 관리 시작:

Systemd는 시스템 시작 시 자동으로 마운트할 수 있도록 시스템의 마운트 지점을 자체 관리합니다. /etc/fstab 파일과 호환됩니다.

트랜잭션 종속성 관리 구현:

systemd는 모든 관련 서비스가 상호의존성이나 교착상태 없이 정상적으로 시작될 수 있도록 "트랜잭션 일관성"이라는 개념을 유지합니다.

내생적 종속성을 기반으로 서비스 제어 로직을 정의합니다. 시스템은 Linux 커널의 기능, 즉 CGroup을 사용하여 프로세스 추적 작업을 완료합니다. 서비스를 중지할 때 CGroup을 쿼리하여 systemd는 모든 관련 프로세스를 찾았는지 확인하여 서비스를 깔끔하게 중지할 수 있습니다.

로그 서비스:

systemd에는 기존 syslog 서비스의 단점을 극복하도록 설계된 자체 로그 서비스 Journald가 제공됩니다.

시스템의 기본 개념

단위 개념:

시스템 초기화를 위해서는 해야 할 일이 많습니다. SSHD 서비스 시작과 같은 백그라운드 서비스를 시작해야 하며 파일 시스템 마운트와 같은 구성 작업을 수행해야 합니다. 이 프로세스의 각 단계는 시스템화에 의해 구성 단위, 즉 단위로 추상화됩니다. 서비스는 구성 단위로, 스왑 파티션의 구성은 구성 단위로 생각할 수 있습니다. systemd는 하이브를 몇 가지 다른 유형으로 분류합니다. 그러나 systemd는 빠르게 발전하고 있으며 새로운 기능이 지속적으로 추가되고 있습니다. 따라서 벌집 유형은 가까운 미래에 계속 증가할 수 있습니다.

service: mysqld와 같은 백그라운드 서비스 프로세스를 나타냅니다. 일반적으로 사용되는 카테고리입니다.

소켓: 이 하이브는 시스템과 인터넷의 소켓을 캡슐화합니다. 현재 systemd는 스트리밍, 패킷 및 연속 패킷 AF_INET, AF_INET6 및 AF_UNIX 소켓을 지원합니다. 모든 소켓 하이브에는 해당 서비스 하이브가 있습니다. 해당 서비스는 첫 번째 "연결"이 소켓에 들어갈 때 시작됩니다(예: nscd.socket은 새 연결 후 nscd.service를 시작합니다).

장치: 이 하이브는 Linux 장치 트리에 존재하는 장치를 캡슐화합니다. udev 규칙으로 태그가 지정된 모든 장치는 systemd에 장치 하이브로 표시됩니다.

마운트: 이 유형의 하이브는 파일 시스템 구조 계층에서 마운트 지점을 캡슐화합니다. Systemd는 이 마운트 지점을 모니터링하고 관리합니다. 예를 들어, 시작 시 자동으로 마운트될 수 있으며 특정 조건에서는 자동으로 제거될 수 있습니다. Systemd는 /etc/fstab의 모든 항목을 마운트 지점으로 변환하고 부팅 시 처리합니다.

automount: 이 유형의 하이브는 시스템 구조 계층 구조에서 자체 마운트 지점을 캡슐화합니다. 각 자체 탑재 하이브는 탑재 하이브에 해당합니다. 자동 탑재 지점에 액세스하면 systemd는 탑재 지점에 정의된 탑재 동작을 실행합니다.

swap: 마운트 하이브와 유사하게 스왑 하이브는 스왑 파티션을 관리하는 데 사용됩니다. 사용자는 스왑 하이브를 사용하여 시스템에서 스왑 파티션을 정의하여 부팅 시 이러한 스왑 파티션이 활성화되도록 할 수 있습니다.

target: 이 하이브는 다른 하이브의 논리적 그룹화를 제공합니다. 그들은 실제로 스스로 아무것도 하지 않으며 단지 다른 벌집을 참조할 뿐입니다. 이를 통해 구성 단위를 통합적으로 제어할 수 있습니다. 이를 통해 친숙한 실행 수준 개념을 구현할 수 있습니다. 예를 들어, 시스템을 그래픽 모드로 전환하려면 많은 서비스와 구성 명령을 실행해야 합니다. 이러한 작업은 구성 단위를 하나씩 대상으로 결합한다는 의미입니다. 한 번 실행되면 대상이 나타내는 시스템 실행 상태로 들어갑니다. (예: multi-user.target은 기존 SysV를 사용하는 시스템의 실행 레벨 3과 동일합니다)

timer: 타이머 구성 단위는 일정한 간격으로 사용자 정의 작업을 트리거하는 데 사용됩니다. 이 유형의 구성 단위는 atd 및 crond와 같은 기존 타이밍 서비스를 대체합니다.

스냅샷: 대상 하이브와 유사하게 스냅샷은 하이브 세트입니다. 시스템의 현재 작동 상태를 저장합니다.

종속성:

systemd는 동시에 시작할 수 있도록 많은 시작 작업에 대한 의존성을 제거합니다. 그러나 여전히 그들 사이에 고유한 종속성을 갖는 일부 작업이 있으며 "소켓 활성화"(소켓 활성화), D-Bus 활성화 및 autofs의 세 가지 주요 방법을 사용하여 종속성을 완화할 수 없습니다(자세한 내용은 후속 설명 참조). 세 가지 주요 방법). 예를 들어, 마운트는 파일 시스템에 마운트 지점이 생성될 때까지 기다려야 하며, 해당 물리적 ​​장치가 준비될 때까지 기다려야 합니다. 이러한 종속성 문제를 해결하기 위해 시스템 구성 단위는 서로 종속성을 정의할 수 있습니다.

Systemd는 하이브 정의 파일의 키워드를 사용하여 하이브 간의 종속성을 설명합니다. 예를 들어, 단위 A는 단위 B의 정의에서 "require A"로 표시될 수 있는 단위 B에 종속됩니다. 이러한 방식으로 systemd는 A가 먼저 시작된 다음 B가 시작되도록 합니다.

시스템 거래:

Systemd는 거래 무결성을 보장할 수 있습니다. Systemd의 트랜잭션 개념은 데이터베이스의 트랜잭션 개념과 다릅니다. 주로 여러 종속 구성 단위 간에 순환 참조가 없도록 보장하는 것입니다. 순환 종속성이 있는 경우 systemd는 어떤 서비스도 시작할 수 없습니다. 하이브 사이에는 두 가지 유형의 종속성이 있으므로 systemd는 이 문제를 해결하려고 시도합니다. 필수는 강한 종속성이고, 원하는 종속성은 약한 종속성을 제거하여 해당 종속성을 깨뜨릴 수 있는지 확인합니다. 주기. 복구할 수 없는 경우 systemd는 오류를 보고합니다.

Systemd는 이러한 구성 오류를 자동으로 감지하고 복구할 수 있으므로 관리자의 문제 해결 부담이 크게 줄어듭니다.

대상 및 실행 수준:

systemd는 실행 수준 개념을 대상으로 대체하여 더 큰 유연성을 제공합니다. 예를 들어 기존 대상을 상속하고 다른 서비스를 추가하여 자신만의 대상을 만들 수 있습니다. 다음 표에는 systemd 및 일반 런레벨 아래의 대상 간의 해당 관계가 나열되어 있습니다.

Systemd 의 동시 시작 원칙

앞서 언급했듯이 Systemd에서는 Avahi, D-Bus, livirtd, X11, HAL 등 모든 서비스가 동시에 시작될 수 있습니다. 언뜻보기에 이것은 약간의 문제처럼 보입니다. 예를 들어 Avahi와 syslog가 동시에 시작된다고 가정하면 syslog는 아직 준비되지 않았지만 Avahi는 기록해야합니다. 로그 문제가 발생하지 않나요?

Systemd 개발자들은 서비스 간 상호의존성의 본질을 주의 깊게 연구한 결과, 소위 종속성이 세 가지 특정 유형으로 나눌 수 있으며, 각 유형은 실제로 해당 기술을 통해 종속성을 제거할 수 있다는 사실을 발견했습니다.

동시 시작의 원칙 중 하나: 소켓 종속성

해결

대부분의 서비스 종속성은 소켓 종속성입니다. 예를 들어 서비스 A는 소켓 포트 S1을 통해 자체 서비스를 제공합니다. 다른 서비스에 서비스 A가 필요한 경우 S1에 연결해야 합니다. 따라서 서비스 A가 아직 시작되지 않은 경우 S1은 존재하지 않으며 다른 서비스에서는 시작 오류가 발생합니다. 따라서 전통적으로 사람들은 서비스 A를 먼저 시작하고 준비 상태가 될 때까지 기다린 다음 이를 필요로 하는 다른 서비스를 시작해야 합니다. Systemd는 S1을 미리 설정하면 서비스 A가 S1을 생성할 때까지 기다리지 않고 다른 모든 서비스를 동시에 시작할 수 있다고 믿습니다. 서비스 A가 시작되지 않은 경우 다른 프로세스에서 S1으로 보낸 서비스 요청은 실제로 Linux 운영 체제에 의해 캐시되며 다른 프로세스는 이 요청 위치에서 대기합니다. 서비스 A가 실행되면 캐시된 요청이 즉시 처리될 수 있으며 모든 것이 정상적으로 실행되기 시작합니다.

그럼 서비스는 init 프로세스에서 생성된 소켓을 어떻게 사용하나요?

Linux 운영 체제에는 프로세스가 하위 프로세스를 생성하기 위해 fork 또는 exec를 호출할 때 상위 프로세스에서 열린 모든 파일 설명자가 하위 프로세스에 상속되는 기능이 있습니다. 소켓은 일종의 파일 핸들이기도 합니다. 프로세스 A는 소켓을 생성할 수 있습니다. 그 후 프로세스 A가 새로운 자식 프로세스를 시작하기 위해 exec를 호출하면 소켓의 close_on_exec 플래그가 지워지는 한 새로운 자식 프로세스가 생성됩니다. 이 소켓을 상속받을 수 있습니다. 자식 프로세스가 보는 소켓과 부모 프로세스가 생성한 소켓은 동일한 시스템 소켓이므로 자식 프로세스 자체가 소켓을 생성한 것처럼 차이가 없습니다.

이 기능은 이전에 inetd라는 시스템 서비스에서 사용되었습니다. Inetd 프로세스는 Telnet과 같은 일부 공통 소켓 포트를 모니터링하는 역할을 합니다. 포트에 연결 요청이 있으면 inetd는 telnetd 프로세스를 시작하고 처리를 위해 연결된 소켓을 새 telnetd 프로세스에 전달합니다. 이런 방식으로 시스템에 텔넷 클라이언트 연결이 없으면 telnetd 프로세스를 시작할 필요가 없습니다. Inetd는 많은 네트워크 서비스를 프록시할 수 있으므로 시스템 로드와 메모리 리소스를 많이 절약할 수 있습니다. 해당 서비스는 실제 연결 요청이 있을 때만 시작되며 소켓은 해당 서비스 프로세스로 전달됩니다.

inetd와 유사하게 systemd는 다른 모든 프로세스의 상위 프로세스입니다. 먼저 필요한 모든 소켓을 설정한 다음 exec를 호출할 때 소켓을 새 서비스 프로세스에 전달하고 새 프로세스는 소켓을 직접 선택하면 됩니다. 전화를 걸어 서비스를 수행합니다.

동시 시작 원칙 2: D-Bus 종속성

해결

D-Bus는 Desktop-Bus의 약어로, 대기 시간이 낮고 오버헤드가 낮으며 가용성이 높은 프로세스 간 통신 메커니즘입니다. 애플리케이션 간의 통신뿐만 아니라 애플리케이션과 운영 체제 커널 간의 통신에도 점점 더 많이 사용되고 있습니다. 많은 최신 서비스 프로세스는 외부 서비스를 제공하기 위한 프로세스 간 통신 메커니즘으로 소켓 대신 D-Bus를 사용합니다. 예를 들어 Linux 네트워크 구성을 단순화하는 NetworkManager 서비스는 D-Bus를 사용하여 다른 애플리케이션이나 서비스와 상호 작용합니다. 이메일 클라이언트 소프트웨어의 발전은 D-Bus를 통해 NetworkManager 서비스에서 네트워크 상태 변경 사항을 가져와 그에 따라 처리할 수 있습니다.

D-Bus는 소위 "버스 활성화" 기능을 지원합니다. 서비스 A가 서비스 B의 D-Bus 서비스를 사용해야 하고 서비스 B가 실행되고 있지 않은 경우 서비스 A가 서비스 B의 D-Bus를 요청할 때 D-Bus는 자동으로 서비스 B를 시작할 수 있습니다. 서비스 A에서 발행한 요청은 D-Bus에 의해 캐시되며 서비스 A는 서비스 B가 준비될 때까지 기다립니다. 이 기능을 사용하면 D-Bus에 의존하는 서비스를 병렬로 시작할 수 있습니다.

동시 시작의 원칙 3: 파일 시스템 종속성 해결

시스템 시작 프로세스 중에 파일 시스템 관련 활동에 가장 많은 시간이 소요됩니다. 예를 들어 파일 시스템 마운트, 파일 시스템에서 디스크 검사(fsck) 수행, 디스크 할당량 검사 등은 모두 시간이 많이 걸립니다. 운영. 이 작업이 완료되기를 기다리는 동안 시스템은 유휴 상태로 유지됩니다. 파일 시스템을 사용하려는 서비스는 시작하기 전에 파일 시스템 초기화가 완료될 때까지 기다려야 하는 것 같습니다. 그러나 systemd는 이러한 종속성을 피할 수도 있다는 것을 발견했습니다.

Systemd는 파일 시스템에 의존하는 서비스와 파일 시스템 자체의 초기화가 동시에 작동할 수 있도록 하는 autofs의 설계 아이디어를 나타냅니다. autofs는 마운트 작업을 트리거하기 전에 파일 시스템 마운트 지점이 실제로 액세스되는 시기를 감지할 수 있습니다. 이는 커널 자동 마운트 모듈의 지원을 통해 달성됩니다. 예를 들어 "/misc/cd/file1"에 대해 open() 시스템 호출이 실행되면 /misc/cd는 아직 마운팅 작업을 수행하지 않은 상태이며 이때 open() 호출은 일시 중지되고 대기합니다. 커널은 autofs에 알리고 autofs는 마운트 작업을 수행합니다. 이때 open() 시스템 호출로 제어권이 반환되어 정상적으로 파일이 열린다.

Systemd는 /home과 같은 시스템의 마운트 지점에 대해 시스템이 시작될 때 autofs 구현을 통합합니다. 현재 /home의 실제 마운트 장치는 아직 시작되지 않았고, 실제 마운트 작업도 수행되지 않았으며, 파일 시스템 검색도 아직 완료되지 않았습니다. 그러나 이 디렉터리에 의존하는 프로세스는 이미 동시에 시작될 수 있으며 해당 open() 작업은 systemd에 내장된 autofs에 의해 캡처되어 open() 호출(휴면 상태를 중단할 수 있음)을 일시 중지합니다. 그런 다음 실제 마운트 작업이 완료되고 파일 시스템 검색이 완료된 후 systemd는 자동 마운트 지점을 실제 마운트 지점으로 바꾸고 open() 호출이 반환되도록 합니다. 결과적으로 파일 시스템과 파일 시스템 자체에 의존하는 서비스를 동시에 시작할 수 있습니다.

물론, "/" 루트 디렉터리에 대한 종속성은 실제로 순차적으로 실행되어야 합니다. 왜냐하면 systemd 자체도 / 아래에 저장되고 시스템 루트 디렉터리가 마운트되고 확인될 때까지 기다려야 하기 때문입니다.

그러나 /home과 같은 마운트 지점의 경우 이러한 동시성은 시스템의 시작 속도를 향상시킬 수 있으며, 특히 /home이 원격 NFS 노드이거나 암호화된 디스크 등인 경우 준비하는 데 시간이 오래 걸리기 때문입니다. 동시 시작의 경우 시스템은 이 기간 동안 아무 작업도 하지 않습니다. 대신 이 여유 시간을 사용하여 더 많은 시작 프로세스를 수행할 수 있으므로 일반적으로 시스템 시작 시간이 단축됩니다.

시스템화됨 사용법

다음은 기술 직원의 다양한 역할에 대한 systemd 사용에 대한 간략한 소개입니다. 이 문서에서는 systemd 사용에 대한 일반적인 이해를 돕기 위해 간단한 설명을 제공할 뿐입니다. 짧은 기사에서 다루기에는 구체적인 세부 사항이 너무 많습니다. 독자는 systemd 문서를 직접 참조해야 합니다.

단위 파일 쓰기

개발자가 httpd와 같은 새로운 서비스 프로그램을 개발할 때 UpStart의 작업 구성 파일과 유사하게 systemd에서 서비스를 관리할 수 있도록 하이브 파일을 작성해야 합니다. 이 파일에서 서비스 시작을 위한 명령줄 구문과 다른 서비스에 대한 종속성을 정의합니다.

또한 systemd에는 서비스 관리뿐만 아니라 마운트 지점 관리, 예약된 작업 정의 등에 사용되는 기능이 많다는 것을 이전에 배웠습니다. 이러한 작업은 해당 하이브 파일을 편집하여 완료됩니다. 여기에는 하이브 파일의 몇 가지 예가 나와 있습니다.

다음은 SSH 서비스의 구성 단위 파일입니다. 서비스 구성 단위 파일에는 파일 이름 접미사가 .service입니다.

[root@kalaguiyin 시스템]# cat/usr/lib/systemd/system/sshd.service

[유닛]

Description=OpenSSH 서버 데몬

After=network.target sshd-keygen.service

Wants=sshd-keygen.service

#[단위] 부분, 설명정보

[서비스]

환경파일=/etc/sysconfig/sshd

ExecStart=/usr/sbin/sshd -D $OPTIONS

ExecReload=/bin/kill -HUP $MAINPID

KillMode=프로세스

다시 시작=실패 시

RestartSec=42초

#[service] 정의, ExecStartPre는 서비스를 시작하기 전에 실행해야 하는 명령을 정의합니다.

#ExecStart는 서비스를 시작하기 위한 특정 명령줄 구문을 정의합니다.

[설치]

WantedBy=multi-user.target

#[install] 섹션: WangtedBy는 이 서비스가 다중 사용자 모드에서 필요함을 나타냅니다.

그럼 multi-user.target을 살펴보겠습니다:

[root@kalaguiyin 시스템]#catmulti-user.target

[유닛]

Description=다중 사용자 시스템

Documentation=man:systemd.special(7)

Requires=basic.target

충돌=rescue.servicerescue.target

After=basic.targetrescue.servicerescue.target

AllowIsolate=yes

# Requires 정의는 multi-user.target이 시작되면 basic.target도 시작되어야 하고, basic.target이 중지되면 multi-user.target도 중지되어야 함을 나타냅니다. 그런 다음 basic.target 파일을 보면 sysinit.target도 지정한다는 것을 알 수 있습니다

# 이에 따라 다른 유닛도 시작해야 합니다. 마찬가지로 sysinit.target에는 다른 유닛도 포함됩니다. 이러한 레이어별 링크 구조를 사용하면 결국 다중 사용자 모드를 지원해야 하는 모든 구성 요소 서비스가 초기화되고 시작됩니다.

[설치]

Alias=default.target

# Alias ​​정의, 즉 이 유닛의 별칭을 정의하여 systemctl 실행 시 이 별칭을 사용하여 이 유닛을 참조할 수 있도록 합니다.

또한 /etc/systemd/system 디렉터리에서 *.wants와 같은 디렉터리를 볼 수도 있습니다. 이 디렉터리에 있는 구성 단위 파일은 [Unit] 섹션의 want 키워드와 동일합니다. 장치가 시작됩니다. 이 장치도 시작해야 합니다. 예를 들어, 직접 작성한 foo.service 파일을 multi-user.target.wants 디렉터리에 넣으면 매번 기본적으로 시작됩니다.

[root@kalaguiyin 시스템]#pwd

/etc/systemd/system

[root@kalaguiyin 시스템]#ls

basic.target.wants                                           display-manager.service

bluetooth.target.wants                                                                                                                                       

dbus-org.bluez.service           graphical.target.wants

printer.target.wants                                                                                               ~                                       소켓.

spice-vdagentd.target.wants                                                                                 default.target.wants

sys-kernel-debug.mout 파일을 다시 살펴보겠습니다. 이 파일은 파일 마운트 지점을 정의합니다.

[root@kalaguiyin 시스템]#cat

sys-kernel-debug.mount

[유닛]

Description=디버그 파일 시스템

Documentation=https://www.kernel.org/doc/Documentation/filesystems/debugfs.txt

Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems

DefaultDependency=아니요

ConditionPathExists=/sys/kernel/debug

이전=sysinit.target

[마운트]

무엇=debugfs

어디=/sys/kernel/debug

유형=debugfs

이 하이브 파일은 마운트 지점을 정의합니다. 탑재 하이브 파일에는 What, Where 및 Type의 세 가지 데이터 항목이 포함된 [Mount] 구성 섹션이 있습니다. 이는 mount 명령에 필요합니다. 예제의 구성은 다음 mount 명령과 동일합니다.

mount –t debugfs /sys/kernel/debug debugfs

Systemd시스템 관리:

systemd의 주요 명령줄 도구는 systemctl입니다.

대부분의 관리자는 서비스 사용, chkconfig 및 telinit 명령과 같은 시스템 서비스 및 초기화 시스템 관리에 이미 매우 익숙해야 합니다. systemd도 동일한 관리 작업을 수행하지만 명령 도구 systemctl의 구문은 다릅니다.

서비스 시작

systemctl은 그림 1과 같이 httpd.service를 시작합니다.

서비스 중지

systemctl은 그림 2와 같이 httpd.service를 중지합니다.

서비스 다시 시작

systemctl restarthttpd.service 그림 3과 같이:

새로고침 서비스

systemctl reloadhttpd.service

조건부 재시작

systemctl condrestarthttpd.service

상태 확인

systemctl statushttpd.service

시작하거나 중지할 수 있는 서비스 목록입니다.

systemctl 목록-단위-파일 –유형=서비스

부팅 시 시작되도록 서비스 설정

chkconfig httpd on

systemctl 활성화httpd.service

서비스 시작 취소;

systemctl 비활성화httpd.service

현재 환경에서 서비스가 활성화 또는 비활성화되도록 구성되어 있는지 확인하세요.

systemctl이 활성화되었습니다httpd.service;echo $?

각 실행 수준에서 서비스 활성화 및 비활성화를 출력

systemctl 목록-단위-파일 – 유형=서비스

서비스가 활성화되고 비활성화되는 실행 수준을 나열합니다.

ls /etc/lib/systemd/system/*.wants/httpd.service

사용자 런레벨 변경:

systemctl isolatemulti-user.target

multi-user.target == 3번째 실행레벨

graphical.target == 5번째 실행 수준

runlevel3.target 다중 사용자.target을 가리키는 심볼릭 링크

runlevel5.target graphic.target을 가리키는 심볼릭 링크

기본 런레벨 변경:

[root@kalaguiyinsystem]# systemctl set-default multi-user.target

rm'/etc/systemd/system/default.target'

ln -s'/usr/lib/systemd/system/multi-user.target''/etc/systemd/system/default.target'

위 작업의 핵심은 /usr/lib/systemd/system/default.target을 삭제한 다음 대상 수준 대상 파일을 /etc/systemd/system/default.target 파일에 연결하는 것입니다.

systemd는 단순한 초기화 시스템 그 이상입니다:

systemd 는 네트워크 구성, Locale 관리, 시스템 커널 모듈 로딩 관리 등과 같은 시스템의 다른 관리 구성도 담당합니다.

Systemd는 sysvinit의 모든 기능을 훌륭하게 대체하지만 여기에 만족하지는 않습니다. init 프로세스는 시스템의 모든 프로세스의 상위 프로세스이기 때문에 systemd는 예약된 작업(이전에는 crond에 의해 완료됨) 세션 관리(이전에는 ConsoleKit/PolKit에 의해 관리됨 등)와 같은 다른 서비스에서 제공되는 기능을 제공하는 데 매우 적합합니다. .). 이 기사의 피상적인 소개만 보면 Systemd는 이미 많은 부분을 처리했지만 여전히 개발 중입니다. 점차적으로 많은 시스템 관리 작업을 처리할 수 있는 다기능 시스템 환경이 될 것입니다. 일부 사람들은 이를 운영 체제로 간주하기도 합니다. 이는 Linux 관리 표준화에 적합합니다!

위 내용은 CentOS 7의 시스템화된 관리 시스템에 대한 심층 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!