충돌 또는 재부팅 후 Linux 서비스가 자동으로 시작되도록 구성하는 방법 - 1부: 실제 예

저자는 Write for DOnations 프로그램을 선택했습니다.

소개

두 부분으로 구성된 이 자습서에서는 systemd를 사용하여 재부팅 또는 충돌 후 자동으로 다시 시작하도록 Linux 서비스를 구성하는 방법을 배웁니다.

1부에서는 init 데몬 및 런레벨과 같은 일반적인 Linux 서비스 관리 개념을 다룹니다. systemd의 서비스 관리 데모로 끝납니다. 여기에서 targets, wants, requires 및 unit 파일을 검사합니다.

2부에서는 실용적이고 일반적인 systemd 작업을 완료하기 위한 단계별 자습서를 제공합니다. 특히 충돌 또는 재부팅 후 자동으로 시작되도록 MySQL 데이터베이스 서버를 구성합니다.

참고: systemd 서비스 및 단위를 제어하기 위해 systemctl을 사용하는 방법에 대한 매우 인기 있는 자습서를 읽는 것도 고려할 수 있습니다.

전제 조건

이 자습서를 완료하려면 다음이 필요합니다.

• Sudo 권한이 있는 루트가 아닌 사용자를 포함하여 CentOS 8을 실행하는 서버. 방화벽을 포함하여 이 모든 것을 설정하려면 초기 서버 설정 가이드를 참조하십시오.

서비스 관리 데몬 소개

Linux 서비스는 주로 init 데몬이라고도 하는 서비스 관리 데몬에 의해 처리되는 방식을 변경하여 자가 치유되도록 할 수 있습니다.

init는 시스템이 부팅되고 커널이 메모리에 로드된 후 Linux 시스템에서 시작되는 첫 번째 프로세스입니다. 무엇보다도 사용자 프로세스 또는 시스템 서비스를 로드하는 방법, 순서 및 자동 시작 여부를 결정합니다.

Linux가 발전함에 따라 init 데몬의 동작도 발전했습니다. 원래 Linux는 Unix에서 사용된 것과 동일한 System V init로 시작했습니다. 그 이후로 Linux는 Upstart init 데몬(Ubuntu에서 생성)과 이제 systemd init 데몬(Fedora에서 처음 구현)을 구현했습니다.

대부분의 최신 Linux 배포판은 System V에서 점진적으로 마이그레이션하여 현재 systemd를 사용하고 있습니다. 이전 스타일 init(사용된 경우)는 이전 버전과의 호환성을 위해서만 유지됩니다. UNIX의 변형인 FreeBSD는 BSD init로 알려진 다른 System V 구현을 사용합니다.

오늘날 Linux 배포판에서 사용되는 가장 최근의 일반적인 서비스 관리자이므로 이 기사에서 systemd를 다룰 것입니다. 그러나 필요한 경우 System V와 Upstart에 대해서도 이야기하고 거기서부터 systemd가 어떻게 발전했는지 살펴보겠습니다. 당신에게 아이디어를 제공하기 위해:

• 시스템 V는 가장 오래된 초기화 시스템으로
에서 사용됩니다.\n
• 데비안 6 이하
• 우분투 9.04 이하
• CentOS 5 이하
• Upstart는 System V 이후에 등장했으며 다음에서 사용되었습니다.
• Ubuntu 9.10에서 Ubuntu 14.04를 포함한 Ubuntu 14.10으로
• 센트OS 6
• systemd는
에서 사용되는 최신 Linux 서비스 관리자입니다.
• 데비안 7 이상
• 우분투 15.04 이상
• CentOS 7 이상

init 데몬을 이해하기 위해 런레벨이라는 것부터 시작하겠습니다.

런레벨

런레벨은 Linux 시스템의 현재 상태를 나타냅니다. 예를 들어 런레벨은 Linux 서버의 종료 상태, 단일 사용자 모드, 재시작 모드 등이 될 수 있습니다. 각 모드는 해당 상태에서 실행할 수 있는 서비스를 지정합니다.

일부 서비스는 하나 이상의 런레벨에서 실행할 수 있지만 다른 서비스에서는 실행할 수 없습니다. 런레벨은 0에서 6 사이의 값으로 표시됩니다. 다음 목록은 이러한 각 레벨의 의미를 보여줍니다.

• 런레벨 0: 시스템 종료
• 런레벨 1: 단일 사용자, 복구 모드
• 런레벨 2, 3, 4: 네트워킹이 활성화된 다중 사용자, 텍스트 모드
• 런레벨 5: 다중 사용자, 네트워크 지원, 그래픽 모드
• 런레벨 6: 시스템 재부팅

런레벨 2, 3, 4는 배포판에 따라 다릅니다. 예를 들어 일부 Linux 배포판은 런레벨 4를 구현하지 않는 반면 다른 배포판은 실행합니다. 일부 분포는 이 세 가지 수준 사이에 명확한 구분이 있습니다. 일반적으로 런레벨 2, 3 또는 4는 Linux가 다중 사용자, 네트워크 사용 가능 텍스트 모드로 부팅된 상태를 의미합니다.

서비스를 자동 시작하도록 활성화하면 Linux는 실제로 서비스를 실행 수준에 추가합니다. 예를 들어 System V에서 OS는 특정 런레벨로 시작합니다. 시작되면 해당 런레벨과 관련된 모든 서비스를 시작하려고 시도합니다. systemd에서는 런레벨이 대상이 되고 서비스가 자동 시작되면 대상에 추가됩니다. 이 문서의 뒷부분에서 대상에 대해 설명합니다.

System V init 데몬 소개

System V는 inittab 파일을 사용하며, 이후의 init 메서드는 이전 버전과의 호환성을 위해 보관했습니다. System V의 시작 순서를 살펴보겠습니다.

1. init 데몬은 바이너리 파일 /sbin/init에서 생성됩니다.
2. init 데몬이 읽는 첫 번째 파일은 /etc/inittab입니다.
3. 이 파일의 항목 중 하나는 시스템이 부팅되어야 하는 런레벨을 결정합니다. 예를 들어 런레벨 값이 3으로 지정된 경우 Linux는 네트워킹이 활성화된 다중 사용자 텍스트 모드로 부팅됩니다. (이 런레벨을 기본 런레벨이라고 합니다.)
4. 다음으로 init 데몬은 /etc/inittab 파일을 자세히 살펴보고 해당 런레벨에 대해 실행해야 하는 init 스크립트를 읽습니다.

따라서 init 데몬이 주어진 실행 수준에 대해 실행해야 하는 init 스크립트를 찾을 때 실제로 시작하는 데 필요한 서비스를 찾는 것입니다. 이러한 init 스크립트는 개별 서비스에 대한 시작 동작을 구성할 수 있는 곳입니다.

init 스크립트는 System V에서 특정 서비스를 제어하는 것입니다. 서비스용 init 스크립트는 애플리케이션 공급업체에서 제공했거나 Linux 배포판(네이티브 서비스용)과 함께 제공되었습니다. 사용자 정의 생성 서비스에 대한 고유한 init 스크립트를 생성할 수도 있습니다.

MySQL Server와 같은 프로세스나 서비스가 System V에서 시작되면 바이너리 프로그램 파일이 메모리에 로드되어야 합니다. 서비스 구성 방식에 따라 이 프로그램은 계속해서 백그라운드를 실행할 수 있습니다(클라이언트 연결 수락). 이 바이너리 애플리케이션을 시작, 중지 또는 다시 로드하는 작업은 서비스의 init 스크립트에 의해 처리됩니다. 서비스를 초기화하기 때문에 init 스크립트라고 합니다.

System V에서 init 스크립트는 쉘 스크립트입니다. rc(실행 명령) 스크립트라고도 합니다. 스크립트는 /etc/init.d 디렉토리 아래에 있습니다. 이 스크립트는 /etc/rc 디렉토리에 심볼릭 링크됩니다. /etc 디렉토리 내에는 각각 이름에 숫자가 있는 다수의 rc 디렉토리가 있습니다. 숫자는 다른 런레벨을 나타냅니다. 따라서 /etc/rc0.d, /etc/rc1.d, /etc/rc2.d 등이 있습니다.

충돌 또는 재부팅 후 서비스를 다시 시작하려면 일반적으로 init 스크립트에 다음과 같은 줄을 추가할 수 있습니다.

ms:2345:respawn:/bin/sh /usr/bin/service_name

시스템 부팅 시 System V 서비스가 시작되도록 하려면 다음 명령을 실행하십시오.

sudo chkconfig service_name on

비활성화하려면 다음 명령을 실행합니다.

sudo chkconfig service_name off

상태(실행 중 또는 중지됨)를 확인하려면 다음 명령을 실행하십시오.

sudo service service_name status

Upstart 데몬 소개

작업 및 서비스를 로드하는 직렬화된 방식이 System V init로 인해 시간이 더 많이 걸리고 복잡해짐에 따라 OS의 더 빠른 로드, 손상된 서비스의 정상적인 정리 및 예측 가능한 종속성을 위해 Upstart 데몬이 도입되었습니다. 시스템 서비스 간.

Upstart init는 몇 가지 면에서 System V init보다 낫습니다.

• 서비스를 로드하고 관리하기 위해 난해한 셸 스크립트를 다루지 않았습니다. 대신 이해하고 수정하기 쉬운 간단한 구성 파일을 사용합니다.
• 시스템 부팅 시간을 줄이는 System V와 같이 서비스가 직렬로 로드되지 않았습니다.
• 다양한 상태에서 서비스를 처리하는 방법을 맞춤화하기 위해 유연한 이벤트 시스템을 사용했습니다.
• Upstart는 충돌한 서비스가 다시 생성되는 방식을 더 잘 처리할 수 있었습니다.
• 동일한 스크립트를 가리키는 많은 중복 심볼릭 링크를 유지할 필요가 없었습니다.

간단하게 유지하기 위해 Upstart는 System V와 역호환됩니다. /etc/init.d/rc 스크립트는 계속 실행되어 기본 System V 서비스를 관리합니다. 주요 차이점은 여러 이벤트를 서비스와 연결하는 방식입니다. 이 이벤트 기반 아키텍처를 통해 Upstart는 유연한 서비스 관리자가 되었습니다. Upstart를 사용하면 각 이벤트가 해당 이벤트를 처리하는 셸 스크립트를 실행할 수 있습니다. 이러한 이벤트에는 다음이 포함됩니다.

• 시작
• 시작
• 중지
• 중지됨

이러한 이벤트 사이에서 서비스는 대기, 사전 시작, 시작, 실행, 사전 중지, 중지 등과 같은 여러 상태에 있을 수 있습니다. Upstart는 이러한 각 상태에 대해 조치를 취할 수 있으므로 매우 유연한 건축학.

시작할 때 Upstart는 모든 System V init 스크립트를 정상적으로 실행합니다. 그런 다음 /etc/init 디렉터리 아래를 살펴보고 각 서비스 구성 파일에서 셸 명령을 실행합니다. 무엇보다도 이러한 파일은 서비스의 시작 동작을 제어했습니다.

파일의 이름 지정 스타일은 service_name.conf이며 스탠자라고 하는 섹션이 다른 일반 텍스트 콘텐츠가 있습니다. 각 스탠자는 서비스의 다양한 측면과 작동 방식을 설명합니다. 충돌 또는 재부팅 후 서비스가 자동으로 시작되도록 하려면 cron 서비스에 대해 아래와 같이 서비스 구성 파일에 respawn 명령을 추가할 수 있습니다.

...

description "regular background program processing daemon"

start on runlevel [2345]

stop on runlevel [!2345]

expect fork

**respawn**

exec cron

systemd 데몬 소개

최신 Linux init 데몬은 systemd입니다. 사실 이것은 init 데몬 이상입니다. systemd는 최신 Linux 시스템의 많은 구성 요소를 포함하는 프레임워크입니다.

기능 중 하나는 Linux용 시스템 및 서비스 관리자로 작동하는 것입니다. 이 용량에서 systemd는 서비스가 충돌하거나 시스템이 재부팅되는 경우 서비스 작동 방식을 제어합니다. 여기에서 systemd의 systemctl에 대해 읽을 수 있습니다.

systemd는 System V 명령 및 초기화 스크립트와 역호환됩니다. 즉, 모든 System V 서비스도 systemd에서 실행됩니다. 이는 대부분의 Upstart 및 System V 관리 명령이 systemd에서 작동하도록 수정되었기 때문에 가능합니다.

systemd 구성 파일: 단위 파일

systemd의 핵심은 단위 파일입니다. 각 단위 파일은 특정 시스템 리소스를 나타냅니다. 리소스에 대한 정보는 단위 파일에서 추적됩니다. 서비스 단위 파일은 선언적 구문이 있는 간단한 텍스트 파일(예: Upstart .conf 파일)입니다. 이렇게 하면 파일을 쉽게 이해하고 수정할 수 있습니다.

systemd와 다른 두 init 방법의 주요 차이점은 systemd가 서비스 데몬 및 장치 운영 체제 경로, 마운트 지점, 소켓 등과 같은 다른 유형의 리소스 초기화를 담당한다는 것입니다. 명명 스타일 단위 파일의 경우 service_name.unit_type입니다. 따라서 dbus.service, sshd.socket 또는 home.mount와 같은 파일이 표시됩니다.

디렉토리 구조

CentOS와 같은 Red Hat 기반 시스템에서는 유닛 파일이 두 곳에 위치합니다. 기본 위치는 /lib/systemd/system/입니다. 사용자 정의 생성 단위 파일 또는 시스템 관리자가 수정한 기존 단위 파일은 /etc/systemd/system 아래에 있습니다.

이름이 같은 단위 파일이 두 위치에 모두 존재하는 경우 systemd는 /etc 아래에 있는 파일을 사용합니다. 서비스가 부팅 시 또는 다른 대상/런레벨에서 시작하도록 활성화되어 있다고 가정합니다. 이 경우 /etc/systemd/system의 해당 디렉토리 아래에 해당 서비스 단위 파일에 대한 심볼릭 링크가 생성됩니다. /etc/systemd/system 아래의 단위 파일은 실제로 /lib/systemd/system 아래에 있는 같은 이름의 파일에 대한 심볼릭 링크입니다.

systemd init 시퀀스: 대상 단위

특수한 유형의 단위 파일은 대상 단위입니다.

대상 장치 파일 이름에는 .target 접미사가 붙습니다. 타겟 유닛은 하나의 특정 리소스를 나타내지 않기 때문에 다른 유닛 파일과 다릅니다. 오히려 그들은 어느 시점의 시스템 상태를 나타냅니다. 대상 유닛은 해당 상태의 일부여야 하는 여러 유닛 파일을 그룹화하고 실행하여 이를 수행합니다. 따라서 systemd 대상은 동일하지는 않지만 System V 런레벨과 느슨하게 비교할 수 있습니다.

각 대상에는 숫자 대신 이름이 있습니다. 예를 들어 runlevel 3 대신 multi-user.target이 있거나 runlevel 6 대신 reboot.target이 있습니다. . Linux 서버가 multi-user.target으로 부팅되면 본질적으로 서버를 다중 사용자 텍스트 모드인 런레벨 2, 3 또는 4로 가져옵니다. 네트워킹이 활성화된 상태에서.

서버를 해당 단계로 가져오는 방법은 차이점이 있습니다. System V와 달리 systemd는 서비스를 순차적으로 가져오지 않습니다. 그 과정에서 다른 서비스나 리소스가 있는지 확인하고 로드 순서를 결정할 수 있습니다. 이렇게 하면 서비스를 병렬로 로드할 수 있습니다.

타겟 유닛과 런레벨의 또 다른 차이점은 System V에서 Linux 시스템은 하나의 런레벨에만 존재할 수 있다는 것입니다. 런레벨을 변경할 수 있지만 시스템은 해당 새 런레벨에만 존재합니다. systemd를 사용하면 대상 유닛이 포괄적일 수 있습니다. 즉, 대상 유닛이 활성화되면 다른 대상 유닛이 그 일부로 로드되도록 할 수 있습니다.

예를 들어, 그래픽 사용자 인터페이스로 부팅하는 Linux 시스템은 graphic.target이 활성화되어 multi-user.target도 자동으로 로드 및 활성화되도록 합니다. System V 측면에서 이는 런레벨 3과 5를 동시에 활성화하는 것과 같습니다.

아래 표는 실행 수준과 대상을 비교합니다.

systemd default.대상

systemd default.target은 System V 기본 런레벨과 동일합니다.

System V에는 inittab이라는 파일에 기본 런레벨이 정의되어 있습니다. systemd에서 해당 파일은 default.target으로 대체됩니다. 기본 대상 유닛 파일은 /etc/systemd/system 디렉토리에 있습니다. /lib/systemd/system 아래의 대상 유닛 파일 중 하나에 대한 심볼릭 링크입니다.

기본 대상을 변경하면 본질적으로 해당 심볼릭 링크를 다시 만들고 시스템의 실행 수준을 변경하는 것입니다.

System V의 inittab 파일은 또한 Linux가 init 스크립트를 실행할 디렉토리를 지정했습니다. rcn.d 디렉토리 중 하나일 수 있습니다. systemd에서 기본 대상 단위는 부팅 시 로드할 리소스 단위를 결정합니다.

장치가 활성화되면 모두 병렬로 또는 모두 순서대로 활성화됩니다. 자원 단위가 로드되는 방식은 원하거나 요구하는 다른 자원 단위에 따라 달라질 수 있습니다.

systemd 종속성: 원하는 것과 요구하는 것

systemd는 systemd가 서비스 데몬 간의 종속성을 해결하는 방법을 제어하기를 원하고 요구합니다.

앞에서 언급했듯이 Upstart는 구성 파일을 사용하여 서비스의 병렬 로드를 보장합니다. System V에서 서비스는 특정 실행 수준에서 시작할 수 있지만 다른 서비스나 리소스를 사용할 수 있을 때까지 대기하도록 만들 수도 있습니다. 유사한 방식으로 systemd 서비스를 하나 이상의 대상에 로드하거나 다른 서비스나 리소스가 활성화될 때까지 기다릴 수 있습니다.

systemd에서 다른 유닛이 필요한 유닛은 필요한 유닛이 로드되고 활성화될 때까지 시작되지 않습니다. 첫 번째 유닛이 활성화되어 있는 동안 어떤 이유로 필요한 유닛이 실패하면 첫 번째 유닛도 중지됩니다.

이것은 시스템 안정성을 보장합니다. 따라서 특정 디렉터리가 있어야 하는 서비스는 해당 디렉터리에 대한 마운트 지점이 활성화될 때까지 대기하도록 만들 수 있습니다. 반면 다른 유닛을 원하는 유닛은 이러한 제한을 두지 않습니다. 발신자가 활성 상태일 때 원하는 장치가 중지되면 중지되지 않습니다. 이에 대한 예는 그래픽 대상 모드에서 나타나는 비필수 서비스입니다.

실용적인 예: systemd 시작 시퀀스 이해

systemd에서 서비스 시작 동작을 이해하기 위해 CentOS 8.3 Droplet을 사용하고 있습니다. 우리는 가능한 한 .target rabbit-track을 따라갈 것입니다. systemd의 시작 순서는 긴 종속성 체인을 따릅니다.

먼저 이 명령을 실행하여 기본 대상 유닛 파일을 나열해 보겠습니다.

sudo ls -l /etc/systemd/system/default.target

다음과 같은 출력이 표시됩니다.

Output
lrwxrwxrwx. 1 root root 37 Dec  4 17:42 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target

보시다시피 기본 대상은 실제로 /lib/systemd/system/ 아래의 다중 사용자 대상 파일에 대한 심볼릭 링크입니다. 따라서 시스템은 System V init의 런레벨 3과 유사한 multi-user.target에서 부팅해야 합니다.

다중 사용자.대상.원함

다음으로 다음 명령을 실행하여 multi-user.target 파일이 원하는 모든 서비스를 확인합니다.

sudo ls -l /etc/systemd/system/multi-user.target.wants/*.service

그러면 /usr/lib/systemd/system/ 아래의 실제 유닛 파일을 다시 가리키는 심볼릭 링크 파일 목록이 표시됩니다.

Output
lrwxrwxrwx. 1 root root 38 Dec  4 17:38 /etc/systemd/system/multi-user.target.wants/auditd.service -> /usr/lib/systemd/system/auditd.service
lrwxrwxrwx. 1 root root 39 Dec  4 17:39 /etc/systemd/system/multi-user.target.wants/chronyd.service -> /usr/lib/systemd/system/chronyd.service
lrwxrwxrwx. 1 root root 37 Dec  4 17:38 /etc/systemd/system/multi-user.target.wants/crond.service -> /usr/lib/systemd/system/crond.service
lrwxrwxrwx. 1 root root 42 Dec  4 17:39 /etc/systemd/system/multi-user.target.wants/irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
lrwxrwxrwx. 1 root root 37 Dec  4 17:41 /etc/systemd/system/multi-user.target.wants/kdump.service -> /usr/lib/systemd/system/kdump.service
...

multi-user.target 외에도 system-update.target 또는 basic.target과 같은 다양한 유형의 대상이 있습니다. 다중 사용자 대상이 의존하는 대상을 보려면 다음 명령을 실행하십시오.

sudo systemctl show --property "Requires" multi-user.target | fmt -10

출력은 다음을 보여줍니다.

Output
Requires=basic.target

기본.대상

다음 명령을 실행하여 basic.target에 필요한 단위가 있는지 확인할 수 있습니다.

sudo systemctl show --property "Requires" basic.target | fmt -10

결과적으로 basic.target에는 sysinit.target이 필요합니다.

Output
Requires=sysinit.target
-.mount

그리고 몇 가지 대상도 필요합니다.

sudo systemctl show --property "Wants" basic.target | fmt -10

이 명령은 다음을 반환합니다.

Output
Wants=slices.target
paths.target
timers.target
microcode.service
sockets.target
sysinit.target

재귀적으로 진행하면 sysinit.target이 다른 대상도 실행해야 하는지 확인할 수 있습니다.

sudo systemctl show --property "Requires" sysinit.target | fmt -10

없을 것입니다. 그러나 sysinit.target이 원하는 다른 대상이 있습니다.

systemctl show --property "Wants" sysinit.target | fmt -10

다음과 같은 출력이 나타납니다.

Output
Wants=systemd-random-seed.service
dev-mqueue.mount
rngd.service
systemd-modules-load.service
proc-sys-fs-binfmt_misc.automount
local-fs.target
sys-fs-fuse-connections.mount
systemd-sysusers.service
systemd-update-done.service
systemd-update-utmp.service
systemd-journal-flush.service
dev-hugepages.mount
dracut-shutdown.service
swap.target
systemd-udevd.service
import-state.service
sys-kernel-debug.mount
nis-domainname.service
systemd-journald.service
selinux-autorelabel-mark.service
kmod-static-nodes.service
loadmodules.service
ldconfig.service
cryptsetup.target
systemd-sysctl.service
systemd-ask-password-console.path
systemd-journal-catalog-update.service
systemd-udev-trigger.service
systemd-tmpfiles-setup.service
systemd-hwdb-update.service
sys-kernel-config.mount
systemd-binfmt.service
systemd-tmpfiles-setup-dev.service
systemd-machine-id-commit.service
systemd-firstboot.service

시스템 단위 파일 검사

이제 한 단계 더 나아가 sshd용 서비스 단위 파일 내부를 살펴보겠습니다.

sudo vi /etc/systemd/system/multi-user.target.wants/sshd.service

다음과 같이 보입니다.

[Unit]
Description=OpenSSH server daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target sshd-keygen.target
Wants=sshd-keygen.target

[Service]
Type=notify
EnvironmentFile=-/etc/crypto-policies/back-ends/opensshserver.config
EnvironmentFile=-/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D $OPTIONS $CRYPTO_POLICY
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

서비스 단위 파일이 깨끗하고 이해하기 쉽다는 것을 알 수 있습니다.

첫 번째 중요한 부분은 [Unit] 섹션의 After 절입니다. 이는 network.target 및 sshd-keygen.target이 로드된 후 sshd 서비스를 로드해야 함을 나타냅니다.

[Install] 섹션은 multi-user.target이 원하는 서비스를 보여줍니다. 이는 multi-user.target이 sshd 데몬을 로드하지만 로드하는 동안 sshd가 실패하더라도 종료되거나 충돌하지 않음을 의미합니다.

multi-user.target이 기본 대상이므로 sshd 데몬은 부팅 시 시작됩니다. [Service] 섹션에서 Restart 매개변수의 값은 on-failure입니다. 이 설정을 사용하면 sshd 데몬이 충돌하거나 비정상적으로 종료된 경우 다시 시작할 수 있습니다.

결론

이 기사에서는 System V, Upstart 및 systemd 서비스 관리 데몬에 대해 배웠습니다. 시작 스크립트 및 구성 파일, 중요한 매개변수, 시작 시퀀스 및 서비스 시작 동작을 제어하는 명령을 살펴보았습니다.

이 기사의 2부에서는 이러한 기술을 실제 예제에 적용하고 systemd를 사용하여 MySQL을 구성합니다. 완료되면 재부팅 또는 충돌 후 MySQL 인스턴스가 자동으로 다시 시작됩니다. 또한 예제 애플리케이션으로 MySQL을 사용하는 동안 Nginx 또는 Apache 웹 서버와 같은 서비스를 얼마든지 대체할 수 있습니다.