10.6. systemd 장치 파일 생성 및 수정

단위 파일은 일반적으로 다음 세 섹션으로 구성됩니다.

단위 구성을 미세 조정하는 데 사용할 수 있는 전체 옵션인 예 10.17. “redfish.service 단위 파일” 은 시스템에 설치된 서비스 단위의 예를 보여줍니다. 또한 단위 파일 옵션은 10.6.5절. “인스턴스화된 유닛으로 작업” 에 설명된 대로 장치를 동적으로 생성하는 방식으로 정의할 수 있습니다.

[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target

장치 파일을 처음부터 생성하는 몇 가지 사용 사례가 있습니다. 사용자 정의 데몬을 실행하거나, 기존 서비스의 두 번째 인스턴스를 생성( 예 10.19. “sshd 서비스의 두 번째 인스턴스 생성”), SysV init 스크립트( 10.6.3절. “SysV Init 스크립트를 유닛 파일로 변환”참조)를 가져올 수 있습니다. 반면 기존 유닛의 동작을 수정하거나 확장하려는 경우 10.6.4절. “기존 장치 파일 수정” 의 지침을 사용합니다. 다음 절차에서는 사용자 지정 서비스를 생성하는 일반적인 프로세스를 설명합니다.

단위 파일의 순서 및 종속 항목에 의해 트리거되는 몇 가지 실제 사례 예제가 있는 추가 정보는 다음 문서에서 확인할 수 있습니다. 유닛 파일 작성에 대한 유용한 정보가 있습니까?

systemd 에 의해 시작된 서비스에 대한 제한을 설정하려면 RHEL 7 및 systemd에서 서비스 제한을 설정하는 방법을 참조하십시오. 이러한 제한은 서비스의 유닛 파일에 설정해야 합니다. systemd 는 /etc/security/limits.conf 및 /etc/security/limits.d/*.conf 구성 파일에 설정된 제한을 무시합니다. 이러한 파일에 정의된 제한은 로그인 세션을 시작할 때 PAM에 의해 설정되지만 systemd 에서 시작한 데몬은 PAM 로그인 세션을 사용하지 않습니다.

SysV init 스크립트를 유닛 파일로 변환하는 데 시간이 걸리기 전에 변환이 아직 다른 곳에서 수행되지 않았는지 확인하십시오. Red Hat Enterprise Linux 7에 설치된 모든 핵심 서비스는 기본 장치 파일과 함께 제공되며 여러 타사 소프트웨어 패키지에 동일하게 적용됩니다.

init 스크립트를 유닛 파일로 변환하려면 스크립트를 분석하고 필요한 정보를 추출해야 합니다. 이 데이터를 기반으로 10.6.2절. “사용자 지정 유닛 파일 생성” 에 설명된 대로 단위 파일을 생성할 수 있습니다. init 스크립트는 서비스 유형에 따라 크게 달라질 수 있으므로 이 장에 설명된 것보다 번역에 더 많은 구성 옵션을 사용해야 할 수 있습니다. init 스크립트에서 사용할 수 있는 일부 수준의 사용자 지정은 더 이상 systemd 장치에서 지원되지 않습니다. 10.1.2절. “호환성 변경”

변환에 필요한 대부분의 정보는 스크립트의 헤더에 제공됩니다. 다음 예제에서는 Red Hat Enterprise Linux 6에서 postfix 서비스를 시작하는 데 사용되는 init 스크립트의 열기 섹션을 보여줍니다.

#!/bin/bash
#
# postfix   Postfix Mail Transfer Agent
#
# chkconfig: 2345 80 30
# description: Postfix is a Mail Transport Agent, which is the program \
#       that moves mail from one machine to another.
# processname: master
# pidfile: /var/spool/postfix/pid/master.pid
# config: /etc/postfix/main.cf
# config: /etc/postfix/master.cf

### BEGIN INIT INFO
# Provides: postfix MTA
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop postfix
# Description: Postfix is a Mail Transport Agent, which is the program that
#       moves mail from one machine to another.
### END INIT INFO

위의 예에서 # chkconfig 및 # 설명으로 시작하는 행만 필수이므로 다른 init 파일에서 나머지를 찾지 못할 수 있습니다. # BEGIN INIT INFO 및 # END INIT INFO 행 사이에 있는 텍스트는 Linux Standard Base(LSB) 헤더 라고 합니다. 지정된 경우 LSB 헤더에는 서비스 설명, 종속 항목 및 기본 실행 수준을 정의하는 지시문이 포함됩니다. 다음은 새 단위 파일에 필요한 데이터를 수집하는 분석 작업의 개요입니다. postfix init 스크립트는 예제로 사용되며 예 10.17. “redfish.service 단위 파일” 에서 결과 postfix 단위 파일을 참조하십시오.

서비스 설명 찾기

#description.로 시작하는 줄에서 스크립트에 대한 설명 정보를 찾을 수 있습니다. 이 설명은 단위 파일의 [Unit] 섹션에 있는 Description 옵션에 있는 서비스 이름과 함께 사용합니다. LSB 헤더는 #Short-Description 및 #Description 행에 유사한 데이터를 포함할 수 있습니다.

서비스 종속성 검색

LSB 헤더에는 서비스 간 종속성을 형성하는 여러 지시문이 포함될 수 있습니다. 대부분의 systemd 장치 옵션은 다음과 같습니다. 표 10.12. “LSB 헤더의 종속성 옵션”

서비스의 기본 대상 검색

#chkconfig 로 시작하는 줄에는 세 개의 숫자 값이 포함되어 있습니다. 가장 중요한 것은 서비스가 시작되는 기본 실행 수준을 나타내는 첫 번째 번호입니다. 표 10.6. “systemd 대상과 SysV Runlevels 비교” 을 사용하여 이러한 실행 수준을 동등한 systemd 대상에 매핑합니다. 그런 다음 장치 파일의 [Install] 섹션에 있는 WantedBy 옵션에 이러한 대상을 나열합니다. 예를 들어 postfix 는 이전에 Red Hat Enterprise Linux 7의 multi-user.target 및 graphical.target으로 변환되는 실행 수준 2, 3, 4 및 5에서 시작되었습니다. graphical.target은 drives.target에 따라 달라지므로 예 10.17. “redfish.service 단위 파일” 에서와 같이 둘 다 지정할 필요는 없습니다. 또한 LSB 헤더에서 #Default-Start 및 #Default-Stop 행에 default 및 금지된 실행 수준 정보에 대한 정보를 찾을 수 있습니다.

#chkconfig 행에 지정된 다른 두 값은 init 스크립트의 시작 및 종료 우선 순위를 나타냅니다. 이러한 값은 init 스크립트를 로드하는 경우 systemd에 의해 해석되지만, 이와 동등한 유닛 파일은 없습니다.

서비스에서 사용하는 파일 찾기

init 스크립트는 전용 디렉터리에서 함수 라이브러리를 로드해야 하며 구성, 환경 및 PID 파일을 가져올 수 있습니다. 환경 변수는 init 스크립트 헤더에서 #config 로 시작하는 행에서 지정되며 EnvironmentFile 장치 파일 옵션으로 변환됩니다. #pidfile init 스크립트 행에 지정된 PID 파일은 PIDFile 옵션을 사용하여 유닛 파일로 가져옵니다.

init 스크립트 헤더에 포함되지 않은 주요 정보는 서비스 실행 파일의 경로이며 서비스에 필요할 가능성이 있는 기타 파일입니다. 이전 버전의 Red Hat Enterprise Linux에서 init 스크립트는 Bash case 문을 사용하여 start,stop, 또는 restart 와 같은 기본 작업에서 서비스 동작을 정의했습니다. postfix init 스크립트에서 발췌한 내용은 service start에서 실행할 코드 블록을 보여줍니다.

conf_check() {
  [ -x /usr/sbin/postfix ] || exit 5
  [ -d /etc/postfix ] || exit 6
  [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
    echo
	return $RETVAL
}

init 스크립트의 확장성을 통해 start() 함수에서 호출되는 conf_check() 및 make_aliasesdb() 를 지정할 수 있습니다. 더 자세히 살펴보면 기본 서비스 실행 /usr/sbin/journal , / etc/journal/ and / var/ spool/ avoided/ 구성 디렉토리 및 /usr/sbin/ postconf/ 디렉토리 등 여러 외부 파일과 디렉터리가 언급됩니다.

systemd는 사전 정의된 작업만 지원하지만 ExecStart ,ExecStartPre, ExecStart Post,ExecStop 및 ExecReload 옵션을 사용하여 사용자 지정 실행 파일을 실행할 수 있습니다. Red Hat Enterprise Linux 7에서 postfix 의 경우 /usr/sbin/ hiera와 지원 스크립트가 함께 서비스 시작 시 실행됩니다. 예 10.17. “redfish.service 단위 파일” 에서 postfix 유닛 파일을 참조하십시오.

복잡한 init 스크립트를 변환하려면 스크립트의 모든 문 용도를 이해해야 합니다. 일부 설명은 운영 체제 버전에 고유하므로 번역할 필요가 없습니다. 반면, 새로운 환경에서는 물론 서비스 실행 파일 및 지원 파일에서도 일부 조정이 필요할 수 있습니다.

시스템에 설치된 서비스는 /usr/lib/systemd/system/ 디렉터리에 저장된 기본 장치 파일과 함께 제공됩니다. 시스템 관리자는 이러한 파일을 직접 수정하지 않아야 하므로 사용자 지정을 /etc/systemd/system/ 디렉터리의 구성 파일로 제한해야 합니다. 필요한 변경의 범위에 따라 다음 방법 중 하나를 선택합니다.

단위의 기본 구성으로 돌아가려면 /etc/systemd/system/.에서 사용자 지정 생성 구성 파일을 삭제하면 됩니다. 시스템을 재부팅하지 않고 장치 파일에 변경 사항을 적용하려면 다음을 실행합니다.

systemctl daemon-reload

daemon-reload 옵션은 모든 유닛 파일을 다시 로드하고 전체 종속성 트리를 다시 생성합니다. 이 트리는 유닛 파일에 변경 사항을 즉시 적용하는 데 필요합니다. 또는 다음 명령을 사용하여 동일한 결과를 얻을 수 있습니다.

init q

또한 수정된 유닛 파일이 실행 중인 서비스에 속하는 경우 새 설정을 수락하려면 이 서비스를 다시 시작해야 합니다.

systemctl restart name.service

기본 장치 구성 확장

추가 구성 옵션을 사용하여 기본 유닛 파일을 확장하려면 먼저 /etc/systemd/system/.에 구성 디렉터리를 만듭니다. 서비스 장치를 확장하는 경우 root 로 다음 명령을 실행합니다.

mkdir /etc/systemd/system/name.service.d/

name 을 확장할 서비스의 이름으로 변경합니다. 위의 구문은 모든 유닛 유형에 적용됩니다.

이전 단계에서 만든 디렉터리에 구성 파일을 생성합니다. 파일 이름은 .conf 접미사로 끝나야 합니다. 유형:

touch /etc/systemd/system/name.service.d/config_name.conf

config_name 을 구성 파일의 이름으로 바꿉니다. 이 파일은 일반 단위 파일 구조를 준수하므로 모든 지시문을 해당 섹션에서 지정해야 합니다. 10.6.1절. “단위 파일 구조 이해”

예를 들어 사용자 지정 종속성을 추가하려면 다음 콘텐츠를 사용하여 구성 파일을 생성합니다.

[Unit]
Requires=new_dependency
After=new_dependency

여기서 new_dependency 는 유닛이 종속성으로 표시됨을 나타냅니다. 또 다른 예로는 기본 프로세스가 종료된 후 서비스를 다시 시작하는 구성 파일이 30초로 지연됩니다.

[Service]
Restart=always
RestartSec=30

하나의 작업에만 중점을 둔 작은 구성 파일을 생성하는 것이 좋습니다. 이러한 파일은 쉽게 이동하거나 다른 서비스의 구성 디렉토리에 연결할 수 있습니다.

단위에 대한 변경 사항을 적용하려면 root 로 실행합니다.

systemctl daemon-reload
systemctl restart name.service

~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf

[Service]
ExecStartPost=/usr/local/bin/custom.sh

~]# systemctl daemon-reload
~]# systemctl restart httpd.service

기본 장치 구성 덮어쓰기

장치 파일을 제공하는 패키지를 업데이트한 후 계속 변경하려면 먼저 파일을 /etc/systemd/system/ 디렉터리에 복사합니다. 이렇게 하려면 root 로 다음 명령을 실행하십시오.

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

여기서 name 은 수정할 서비스 유닛의 이름을 나타냅니다. 위의 구문은 모든 유닛 유형에 적용됩니다.

텍스트 편집기로 복사된 파일을 열고 원하는 대로 변경합니다. 단위 변경 사항을 적용하려면 root 로 실행합니다.

systemctl daemon-reload
systemctl restart name.service

Monitoring Overriden Units

재정의 또는 수정된 단위 파일의 개요를 표시하려면 다음 명령을 사용합니다.

systemd-delta

예를 들어 위 명령의 출력은 다음과 같습니다.

[EQUIVALENT] /etc/systemd/system/default.target  /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service  /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service   2014-10-16 21:30:39.000000000 -0400
+++ /etc/systemd/system/autofs.service 2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always

 [Install]
 WantedBy=multi-user.target

[MASKED]   /etc/systemd/system/cups.service  /usr/lib/systemd/system/cups.service
[EXTENDED]  /usr/lib/systemd/system/sssd.service  /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.

표 10.13. “systemd-delta Difference Types” systemd-delta 의 출력에 표시될 수 있는 덮어쓰기 유형을 나열합니다. 파일을 재정의하는 경우 기본적으로 systemd-delta 는 diff 명령의 출력과 유사한 변경 사항에 대한 요약을 표시합니다.

시스템 업데이트 후에 systemd-delta 를 실행하여 현재 사용자 지정 구성으로 재정의된 기본 유닛에 대한 업데이트가 있는지 확인하는 것이 좋습니다. 출력을 특정 차이 유형으로만 제한할 수도 있습니다. 예를 들어 재정의된 장치만 보려면 다음을 실행합니다.

systemd-delta --type=overridden

런타임 시 단일 템플릿 구성 파일에서 여러 단위를 인스턴스화할 수 있습니다. "@" 문자는 템플릿을 표시하고 장치와 장치를 연결하는 데 사용됩니다. 인스턴스화된 단위는 다른 유닛 파일( Requires 또는 Wants 옵션 사용) 또는 systemctl start 명령으로 시작할 수 있습니다. 인스턴스화된 서비스 유닛의 이름은 다음과 같습니다.

template_name@instance_name.service

여기서 template_name 은 템플릿 구성 파일의 이름을 나타냅니다. instance_name 을 유닛 인스턴스의 이름으로 바꿉니다. 여러 인스턴스는 장치의 모든 인스턴스에 공통된 구성 옵션을 사용하여 동일한 템플릿 파일을 가리킬 수 있습니다. 템플릿 단위 이름에는 다음과 같은 형식이 있습니다.

unit_name@.service

예를 들어, 단위 파일의 다음 Wants 설정:

Wants=getty@ttyA.service,getty@ttyB.service

먼저 systemd가 지정된 서비스 장치를 검색합니다. 이러한 유닛을 찾을 수 없는 경우 "@"과 유형 접미사 사이의 일부가 무시되고, systemd는 getty@.service 파일을 검색하고, 해당 파일에서 구성을 읽고, 서비스를 시작합니다.

단위 지정자 라고 하는 와일드카드 문자를 모든 단위 구성 파일에 사용할 수 있습니다. 단위 지정자는 특정 단위 매개 변수를 대체하고 런타임 시 해석됩니다. 표 10.14. “중요 단위 지정기” 템플릿 단위에 특히 유용한 단위 연산자를 나열합니다.

단위 연산자의 전체 목록은 systemd.unit(5) 매뉴얼 페이지를 참조하십시오.

예를 들어 getty@.service 템플릿에는 다음 지시문이 포함되어 있습니다.

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...

getty@ttyA.service 및 getty@ttyB.service가 인스턴스화되면 위의 템플릿이 Description=은 ttyA 및 Getty on tty B 로 확인됩니다.