Type은 simple, exec, forking, oneshot, dbus, notify, notify-reload, idle 중에 하나를 사용할 수 있다.
- simple: simple로 설정하면(ExecStart=가 지정되었지만 Type=이나 BusName=이 지정되지 않은 경우 기본값) 서비스 관리자는 기본 서비스 프로세스가 분기된 직후 장치가 시작된 것으로 간주합니다. ExecStart=로 구성된 프로세스가 서비스의 주요 프로세스가 될 것으로 예상됩니다. 이 모드에서 프로세스가 시스템의 다른 프로세스에 기능을 제공하는 경우 서비스가 시작되기 전에 통신 채널이 설치되어야 합니다(예: 소켓 활성화를 통해 systemd에 의해 설정된 소켓). 서비스 관리자는 즉시 이어지는 유닛 실행을 진행하고, 바로 메인 서비스 프로세스를 생성하기 때문입니다. 이는 간단한 서비스에 대한 systemctl start 명령줄이 서비스의 바이너리를 성공적으로 호출할 수 없는 경우에도 성공을 보고한다는 의미입니다(예: 선택한 User=가 존재하지 않거나 서비스 바이너리가 누락된 경우).
- exec: exec 유형은 simple과 유사하지만 서비스 관리자는 기본 서비스 바이너리가 실행된 직후 장치가 시작된 것으로 간주합니다. 서비스 관리자는 해당 시점까지 후속 작업 시작을 연기합니다. (즉, 간단하게 fork() 반환 직후 추가 작업을 진행하는 반면, exec는 서비스 프로세스에서 fork()와 execve()가 모두 성공하기 전에는 진행하지 않습니다.) 이는 exec 서비스에 대한 systemctl start 명령줄을 의미합니다. 서비스의 바이너리를 성공적으로 호출할 수 없는 경우 실패를 보고합니다(예: 선택한 User=가 존재하지 않거나 서비스 바이너리가 누락된 경우).
- fork: 포크로 설정하면 ExecStart=로 구성된 프로세스가 시작의 일부로 fork()를 호출할 것으로 예상됩니다. 상위 프로세스는 시작이 완료되고 모든 통신 채널이 설정되면 종료될 것으로 예상됩니다. 하위 프로세스는 기본 서비스 프로세스로 계속 실행되며 서비스 관리자는 상위 프로세스가 종료될 때 단위가 시작된 것으로 간주합니다. 이것은 전통적인 UNIX 서비스의 동작입니다. 이 설정을 사용하는 경우 systemd가 서비스의 주요 프로세스를 안정적으로 식별할 수 있도록 PIDFile= 옵션도 사용하는 것이 좋습니다. systemd는 상위 프로세스가 종료되는 즉시 후속 조치 시작을 진행합니다.
- oneshot: oneshot의 동작은 simple과 비슷합니다. 그러나 서비스 관리자는 기본 프로세스가 종료된 후 장치가 작동하는 것으로 간주합니다. 그런 다음 후속 장치를 시작합니다. RemainAfterExit=는 이러한 유형의 서비스에 특히 유용합니다. Type=oneshot은 Type=도 ExecStart=도 지정되지 않은 경우 묵시적 기본값입니다. RemainAfterExit= 없이 이 옵션을 사용하면 서비스가 "활성" 장치 상태로 들어가지 않고 계속 실행되도록 구성된 프로세스가 없기 때문에 "활성화"에서 "비활성화" 또는 "죽음"으로 직접 전환됩니다. 특히 이것은 이 유형의 서비스가 실행된 후(그리고 RemainAfterExit=가 설정되지 않음) 나중에 시작된 것으로 표시되지 않고 죽은 것으로 표시됨을 의미합니다.
- dbus: dbus의 동작은 단순함과 유사합니다. 그러나 서비스는 BusName=에 의해 구성된 대로 D-Bus 버스에서 이름을 획득할 것으로 예상됩니다. systemd는 D-Bus 버스 이름을 획득한 후 후속 유닛 시작을 진행합니다. 이 옵션이 구성된 서비스 장치는 암시적으로 dbus.socket 장치에 대한 종속성을 얻습니다. 이 유형은 BusName=이 지정된 경우 기본값입니다. 이 유형의 서비스 단위는 지정된 버스 이름을 얻을 때까지 활성화 상태에 있는 것으로 간주됩니다. 버스 이름이 사용되는 동안 활성화된 것으로 간주됩니다. 버스 이름이 해제되면 서비스는 더 이상 작동하지 않는 것으로 간주되어 서비스 관리자가 서비스에 속한 나머지 프로세스를 종료하려고 합니다. 종료 논리의 일부로 버스 이름을 삭제하는 서비스는 결과적으로 SIGTERM(또는 KillSignal=에 구성된 신호)을 수신할 준비가 되어 있어야 합니다.
- notify: notify의 동작은 exec와 유사합니다. 그러나 서비스가 시작을 완료하면 sd_notify(3) 또는 동등한 호출을 통해 "READY=1" 알림 메시지를 보낼 것으로 예상됩니다. systemd는 이 알림 메시지가 전송된 후 후속 장치 시작을 진행합니다. 이 옵션을 사용하는 경우 NotifyAccess=(아래 참조)는 systemd에서 제공하는 알림 소켓에 대한 액세스를 열도록 설정해야 합니다. NotifyAccess=가 없거나 없음으로 설정된 경우 강제로 기본으로 설정됩니다.
- notify-reload: notify-reload의 동작은 notify와 동일합니다. 그러나 한 가지 방식으로 논리를 확장합니다. 서비스를 다시 로드하라는 요청을 받으면 SIGHUP UNIX 프로세스 신호가 서비스의 기본 프로세스로 전송됩니다. (전송할 신호는 ReloadSignal=을 통해 조정할 수 있습니다. 아래 참조). 다시 로드 프로세스를 시작할 때 서비스는 현재 단조 시간(예: clock_gettime(2 )) µs 단위로 10진수 문자열 형식입니다. 다시 로드가 완료되면 "READY=1"을 포함하는 다른 알림 메시지를 보내야 합니다. 이 서비스 유형을 사용하고 이 다시 로드 프로토콜을 구현하는 것은 서비스 구성을 다시 로드하기 위해 ExecReload= 명령을 제공하는 것보다 효율적인 대안입니다.
- idle: 유휴 동작은 단순 동작과 매우 유사합니다. 그러나 서비스 프로그램의 실제 실행은 모든 활성 작업이 발송될 때까지 지연됩니다. 콘솔의 상태 출력과 셸 서비스 출력의 인터리브를 방지하는 데 사용할 수 있습니다. 이 유형은 콘솔 출력을 개선하는 데만 유용하고 일반 장치 주문 도구로는 유용하지 않으며 이 서비스 유형의 효과는 5초 시간 제한이 적용되며 그 후에는 서비스 프로그램이 호출됩니다.