Systemctl을 사용하여 Systemd 서비스 및 단위를 관리하는 방법

소개

systemd는 Linux 배포판의 새로운 표준이 된 초기 시스템 및 시스템 관리자입니다. 채택률이 높기 때문에 systemd에 익숙해지면 서버 관리가 훨씬 쉬워지므로 그만한 가치가 있습니다. systemd를 구성하는 도구와 데몬에 대해 배우고 사용하면 그것이 제공하는 힘, 유연성 및 기능을 더 잘 이해하는 데 도움이 되거나 최소한 번거로움 없이 작업을 수행하는 데 도움이 됩니다.

이 가이드에서는 init 시스템을 제어하기 위한 중앙 관리 도구인 systemctl 명령에 대해 설명합니다. 서비스 관리, 상태 확인, 시스템 상태 변경 및 구성 파일 작업 방법을 다룹니다.

systemd가 많은 Linux 배포판의 기본 초기 시스템이 되었지만 모든 배포판에서 보편적으로 구현되지는 않습니다. 이 자습서를 진행하면서 터미널에서 bash: systemctl이 설치되지 않음 오류를 출력하면 컴퓨터에 다른 초기화 시스템이 설치되었을 가능성이 있습니다.

서비스 관리

init 시스템의 기본 목적은 Linux 커널이 부팅된 후 시작해야 하는 구성 요소(전통적으로 "userland\ 구성 요소로 알려짐)를 초기화하는 것입니다. init 시스템은 또한 어느 시점에서든 서버의 서비스 및 데몬을 관리하는 데 사용됩니다. 시스템이 실행되는 동안 이를 염두에 두고 기본적인 서비스 관리 작업부터 시작하겠습니다.

systemd에서 대부분의 작업 대상은 systemd가 관리 방법을 알고 있는 리소스인 "단위\입니다. 단위는 나타내는 리소스 유형에 따라 분류되며 단위 파일로 알려진 파일로 정의됩니다. 각 단위의 유형은 파일 끝에 있는 접미사에서 유추할 수 있습니다.

서비스 관리 작업의 대상 단위는 .service 접미사가 있는 단위 파일이 있는 서비스 단위입니다. 그러나 대부분의 서비스 관리 명령의 경우 실제로 .service 접미사를 생략할 수 있습니다. 서비스 관리 명령.

서비스 시작 및 중지

systemd 서비스를 시작하려면 서비스의 단위 파일에서 명령을 실행하고 start 명령을 사용하십시오. 루트가 아닌 사용자로 실행 중인 경우 운영 체제 상태에 영향을 미치므로 sudo를 사용해야 합니다.

sudo systemctl start application.service

위에서 언급했듯이 systemd는 서비스 관리 명령에 대한 *.service 파일을 찾는 것을 알고 있으므로 명령을 다음과 같이 입력할 수 있습니다.

sudo systemctl start application

일반적인 관리를 위해 위의 형식을 사용할 수 있지만 명확성을 위해 나머지 명령에 .service 접미사를 사용하여 작업 중인 대상에 대해 명시적으로 설명합니다.

현재 실행 중인 서비스를 중지하려면 대신 stop 명령을 사용할 수 있습니다.

sudo systemctl stop application.service

다시 시작 및 다시 로드

실행 중인 서비스를 다시 시작하려면 restart 명령을 사용할 수 있습니다.

sudo systemctl restart application.service

해당 응용 프로그램이 (다시 시작하지 않고) 구성 파일을 다시 로드할 수 있는 경우 reload 명령을 실행하여 해당 프로세스를 시작할 수 있습니다.

sudo systemctl reload application.service

서비스에 구성을 다시 로드하는 기능이 있는지 확실하지 않은 경우 reload-or-restart 명령을 실행할 수 있습니다. 가능한 경우 구성을 제자리에서 다시 로드합니다. 그렇지 않으면 새 구성이 선택되도록 서비스를 다시 시작합니다.

sudo systemctl reload-or-restart application.service

서비스 활성화 및 비활성화

위의 명령은 현재 세션 중에 서비스를 시작하거나 중지하는 데 유용합니다. 부팅 시 서비스를 자동으로 시작하도록 systemd에 지시하려면 서비스를 활성화해야 합니다.

부팅 시 서비스를 시작하려면 enable 명령을 사용하십시오.

sudo systemctl enable application.service

이렇게 하면 시스템의 서비스 파일 복사본(일반적으로 /lib/systemd/system 또는 /etc/systemd/system)에서 디스크의 위치로 심볼릭 링크가 생성됩니다. 여기서 systemd는 자동 시작 파일을 찾습니다(일반적으로 /etc/systemd/system/some_target.target.wants. 대상이 무엇인지 살펴보겠습니다. 이 가이드의 뒷부분에서).

서비스가 자동으로 시작되지 않도록 하려면 다음을 입력하십시오.

sudo systemctl disable application.service

이렇게 하면 서비스가 자동으로 시작되어야 함을 나타내는 심볼릭 링크가 제거됩니다.

서비스를 활성화해도 현재 세션에서 서비스가 시작되지 않는다는 점에 유의하십시오. 서비스를 시작하고 부팅 시 활성화하려면 start 및 enable 명령을 모두 실행해야 합니다.

서비스 상태 확인

시스템의 서비스 상태를 확인하려면 status 명령을 사용할 수 있습니다.

systemctl status application.service

이것은 서비스 상태, cgroup 계층 및 처음 몇 개의 로그 행을 제공합니다.

예를 들어 Nginx 서버의 상태를 확인할 때 다음과 같은 출력이 표시될 수 있습니다.

Output● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2015-01-27 19:41:23 EST; 22h ago
 Main PID: 495 (nginx)
   CGroup: /system.slice/nginx.service
           ├─495 nginx: master process /usr/bin/nginx -g pid /run/nginx.pid; error_log stderr;
           └─496 nginx: worker process
Jan 27 19:41:23 desktop systemd[1]: Starting A high performance web server and a reverse proxy server...
Jan 27 19:41:23 desktop systemd[1]: Started A high performance web server and a reverse proxy server.

이는 응용 프로그램의 현재 상태에 대한 좋은 개요를 제공하여 필요한 모든 문제 및 조치를 알려줍니다.

특정 상태를 확인하는 방법도 있습니다. 예를 들어 유닛이 현재 활성(실행 중)인지 확인하려면 is-active 명령을 사용할 수 있습니다.

systemctl is-active application.service

이렇게 하면 일반적으로 활성 또는 비활성인 현재 장치 상태가 반환됩니다. 종료 코드는 활성 상태인 경우 "0\이 되어 쉘 스크립트에서 결과를 더 간단하게 구문 분석할 수 있습니다.

장치가 활성화되었는지 확인하려면 is-enabled 명령을 사용할 수 있습니다.

systemctl is-enabled application.service

이렇게 하면 서비스가 활성화인지 비활성화인지 출력되고 명령 질문에 대한 답변에 따라 종료 코드가 "0” 또는 "1”로 다시 설정됩니다.

세 번째 확인은 장치가 고장난 상태인지 여부입니다. 이는 해당 장치를 시작하는 데 문제가 있음을 나타냅니다.

systemctl is-failed application.service

제대로 실행 중인 경우 active를 반환하고 오류가 발생한 경우 failed를 반환합니다. 장치가 의도적으로 중지된 경우 알 수 없음 또는 비활성을 반환할 수 있습니다. "0\의 종료 상태는 실패가 발생했음을 나타내고 "1\의 종료 상태는 다른 모든 상태를 나타냅니다.

시스템 상태 개요

지금까지의 명령어들은 단일 서비스를 관리하는 데는 유용했지만 시스템의 현재 상태를 탐색하는 데는 그다지 도움이 되지 않습니다. 이 정보를 제공하는 많은 systemctl 명령이 있습니다.

현재 단위 나열

systemd가 알고 있는 모든 활성 단위 목록을 보려면 list-units 명령을 사용할 수 있습니다.

systemctl list-units

그러면 systemd가 현재 시스템에서 활성화한 모든 장치 목록이 표시됩니다. 출력은 다음과 같습니다.

OutputUNIT                                      LOAD   ACTIVE SUB     DESCRIPTION
atd.service                               loaded active running ATD daemon
avahi-daemon.service                      loaded active running Avahi mDNS/DNS-SD Stack
dbus.service                              loaded active running D-Bus System Message Bus
dcron.service                             loaded active running Periodic Command Scheduler
dkms.service                              loaded active exited  Dynamic Kernel Modules System
getty@tty1.service                        loaded active running Getty on tty1
. . .

출력에는 다음 열이 있습니다.

UNIT: systemd 단위 이름
LOAD: 단위 구성이 systemd에 의해 파싱되었는지 여부. 로드된 장치의 구성은 메모리에 보관됩니다.
ACTIVE: 장치의 활성 여부에 대한 요약 상태입니다. 이는 일반적으로 장치가 성공적으로 시작되었는지 여부를 확인하는 매우 기본적인 방법입니다.
SUB: 장치에 대한 자세한 정보를 나타내는 하위 수준 상태입니다. 이것은 종종 장치 유형, 상태 및 장치가 실행되는 실제 방법에 따라 다릅니다.
설명: 단위가 무엇인지/하는 일에 대한 간단한 텍스트 설명

list-units 명령은 기본적으로 활성 유닛만 표시하므로 위의 모든 항목은 LOAD 열에 loaded가 표시되고 활성 열. 이 디스플레이는 실제로 추가 명령 없이 호출될 때 systemctl의 기본 동작이므로 인수 없이 systemctl을 호출하면 동일한 내용이 표시됩니다.

systemctl

추가 플래그를 추가하여 systemctl에 다른 정보를 출력하도록 지시할 수 있습니다. 예를 들어 systemd가 로드한(또는 로드하려고 시도한) 모든 단위를 보려면 현재 활성화 여부에 관계없이 --all 플래그를 사용할 수 있습니다. , 이와 같이:

systemctl list-units --all

이것은 시스템의 현재 상태에 관계없이 systemd가 로드했거나 로드하려고 시도한 모든 유닛을 표시합니다. 일부 장치는 실행 후 비활성화되고 systemd가 로드하려고 시도한 일부 장치는 디스크에서 발견되지 않았을 수 있습니다.

다른 플래그를 사용하여 이러한 결과를 필터링할 수 있습니다. 예를 들어 --state= 플래그를 사용하여 보려는 LOAD, ACTIVE 또는 SUB 상태를 나타낼 수 있습니다. systemctl이 비활성 장치를 표시할 수 있도록 --all 플래그를 유지해야 합니다.

systemctl list-units --all --state=inactive

또 다른 일반적인 필터는 --type= 필터입니다. 관심 있는 유형의 단위만 표시하도록 systemctl에 지시할 수 있습니다. 예를 들어 활성 서비스 단위만 보려면 다음을 사용할 수 있습니다.

systemctl list-units --type=service

모든 단위 파일 나열

list-units 명령은 systemd가 구문 분석하여 메모리에 로드하려고 시도한 단위만 표시합니다. systemd는 필요하다고 생각되는 단위만 읽기 때문에 시스템에서 사용 가능한 모든 단위가 반드시 포함되는 것은 아닙니다. systemd가 로드를 시도하지 않은 파일을 포함하여 systemd 경로 내에서 사용 가능한 모든 단위 파일을 보려면 목록을 사용할 수 있습니다. -unit-files 명령 대신:

systemctl list-unit-files

단위는 systemd가 알고 있는 리소스를 나타냅니다. systemd는 이 보기의 모든 단위 정의를 반드시 읽지 않았기 때문에 파일 자체에 대한 정보만 제공합니다. 출력에는 단위 파일과 상태라는 두 개의 열이 있습니다.

OutputUNIT FILE                                  STATE
proc-sys-fs-binfmt_misc.automount          static
dev-hugepages.mount                        static
dev-mqueue.mount                           static
proc-fs-nfsd.mount                         static
proc-sys-fs-binfmt_misc.mount              static
sys-fs-fuse-connections.mount              static
sys-kernel-config.mount                    static
sys-kernel-debug.mount                     static
tmp.mount                                  static
var-lib-nfs-rpc_pipefs.mount               static
org.cups.cupsd.path                        enabled
. . .

상태는 일반적으로 활성화, 비활성화, 정적 또는 마스킹됨입니다. 이 문맥에서 정적이란 유닛 파일에 유닛을 활성화하는 데 사용되는 install 섹션이 포함되어 있지 않음을 의미합니다. 따라서 이러한 단위는 활성화할 수 없습니다. 일반적으로 이것은 장치가 일회성 작업을 수행하거나 다른 장치의 종속성으로만 사용되며 자체적으로 실행되어서는 안 됨을 의미합니다.

잠시 동안 masked가 무엇을 의미하는지 다룰 것입니다.

단위 관리

지금까지 우리는 서비스에 대해 작업하고 systemd가 알고 있는 단위 및 단위 파일에 대한 정보를 표시했습니다. 그러나 몇 가지 추가 명령을 사용하여 단위에 대한 보다 구체적인 정보를 찾을 수 있습니다.

단위 파일 표시

systemd가 시스템에 로드한 단위 파일을 표시하려면 cat 명령을 사용할 수 있습니다(systemd 버전 209에 추가됨). 예를 들어 atd 스케줄링 데몬의 단위 파일을 보려면 다음과 같이 입력할 수 있습니다.

systemctl cat atd.service

Output[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

출력은 현재 실행 중인 systemd 프로세스에 알려진 단위 파일입니다. 이것은 최근에 단위 파일을 수정했거나 단위 파일 조각에서 특정 옵션을 무시하는 경우 중요할 수 있습니다(나중에 다룰 것입니다).

종속성 표시

장치의 종속성 트리를 보려면 list-dependencies 명령을 사용할 수 있습니다.

systemctl list-dependencies sshd.service

그러면 해당 장치를 시작하기 위해 처리해야 하는 종속성을 매핑하는 계층 구조가 표시됩니다. 이 컨텍스트에서 종속성에는 상위 단위에서 필요로 하거나 원하는 단위가 포함됩니다.

Outputsshd.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
. . .

재귀 종속성은 시스템 상태를 나타내는 .target 단위에 대해서만 표시됩니다. 모든 종속성을 재귀적으로 나열하려면 --all 플래그를 포함합니다.

역 종속성(지정된 단위에 의존하는 단위)을 표시하려면 명령에 --reverse 플래그를 추가할 수 있습니다. 유용한 다른 플래그는 --before 및 --after 플래그로, 각각 이전과 이후에 시작하는 지정된 단위에 의존하는 단위를 표시하는 데 사용할 수 있습니다. .

장치 속성 확인

장치의 하위 수준 속성을 보려면 show 명령을 사용할 수 있습니다. 그러면 key=value 형식을 사용하여 지정된 장치에 대해 설정된 속성 목록이 표시됩니다.

systemctl show sshd.service

OutputId=sshd.service
Names=sshd.service
Requires=basic.target
Wants=system.slice
WantedBy=multi-user.target
Conflicts=shutdown.target
Before=shutdown.target multi-user.target
After=syslog.target network.target auditd.service systemd-journald.socket basic.target system.slice
Description=OpenSSH server daemon
. . .

단일 속성을 표시하려면 속성 이름과 함께 -p 플래그를 전달할 수 있습니다. 예를 들어 sshd.service 단위에 있는 충돌을 보려면 다음을 입력할 수 있습니다.

systemctl show sshd.service -p Conflicts

OutputConflicts=shutdown.target

마스킹 및 마스킹 해제 장치

서비스 관리 섹션에서 서비스를 중지하거나 비활성화하는 방법을 보았지만 systemd에는 장치를 연결하여 자동 또는 수동으로 장치를 완전히 시작할 수 없는 것으로 표시하는 기능도 있습니다. /dev/null로. 이를 유닛 마스킹이라고 하며 mask 명령으로 가능합니다.

sudo systemctl mask nginx.service

이렇게 하면 마스킹된 동안 Nginx 서비스가 자동 또는 수동으로 시작되지 않습니다.

list-unit-files를 확인하면 서비스가 마스킹된 것으로 표시됩니다.

systemctl list-unit-files

Output. . .
kmod-static-nodes.service              static
ldconfig.service                       static
mandb.service                          static
messagebus.service                     static
nginx.service                          masked
quotaon.service                        static
rc-local.service                       static
rdisc.service                          disabled
rescue.service                         static
. . .

서비스를 시작하려고 하면 다음과 같은 메시지가 표시됩니다.

sudo systemctl start nginx.service

OutputFailed to start nginx.service: Unit nginx.service is masked.

장치의 마스크를 해제하여 다시 사용할 수 있도록 하려면 unmask 명령을 사용하십시오.

sudo systemctl unmask nginx.service

이렇게 하면 장치가 이전 상태로 돌아가서 시작하거나 활성화할 수 있습니다.

단위 파일 편집

단위 파일의 특정 형식은 이 자습서의 범위를 벗어나지만 systemctl은 조정이 필요한 경우 단위 파일을 편집하고 수정할 수 있는 기본 제공 메커니즘을 제공합니다. 이 기능은 systemd 버전 218에 추가되었습니다.

기본적으로 edit 명령은 해당 단위에 대한 단위 파일 스니펫을 엽니다.

sudo systemctl edit nginx.service

이것은 장치 정의에 지시문을 재정의하거나 추가하는 데 사용할 수 있는 빈 파일입니다. .d가 추가된 장치 이름을 포함하는 /etc/systemd/system 디렉토리 내에 디렉토리가 생성됩니다. 예를 들어 nginx.service의 경우 nginx.service.d라는 디렉토리가 생성됩니다.

이 디렉토리 내에서 override.conf라는 스니펫이 생성됩니다. 유닛이 로드되면 systemd는 메모리에서 오버라이드 스니펫을 전체 유닛 파일과 병합합니다. 스니펫의 지시어는 원본 단위 파일에 있는 지시어보다 우선합니다.

스니펫을 만드는 대신 전체 단위 파일을 편집하려면 --full 플래그를 전달할 수 있습니다.

sudo systemctl edit --full nginx.service

이렇게 하면 현재 단위 파일이 편집기에 로드되어 수정할 수 있습니다. 편집기가 종료되면 변경된 파일이 /etc/systemd/system에 기록되며 시스템 단위 정의보다 우선합니다(보통 /lib/systemd/system).

추가한 내용을 제거하려면 장치의 .d 구성 디렉토리 또는 /etc/systemd/system에서 수정된 서비스 파일을 삭제하십시오. 예를 들어 스니펫을 제거하려면 다음과 같이 입력할 수 있습니다.

sudo rm -r /etc/systemd/system/nginx.service.d

수정된 전체 단위 파일을 제거하려면 다음을 입력합니다.

sudo rm /etc/systemd/system/nginx.service

파일이나 디렉터리를 삭제한 후에는 systemd 프로세스를 다시 로드하여 더 이상 이러한 파일을 참조하려고 시도하지 않고 시스템 복사본을 사용하도록 되돌려야 합니다. 다음을 입력하면 됩니다.

sudo systemctl daemon-reload

대상으로 시스템 상태(런레벨) 조정

대상은 시스템 상태 또는 동기화 지점을 설명하는 특수 단위 파일입니다. 다른 단위와 마찬가지로 대상을 정의하는 파일은 해당 접미사로 식별할 수 있습니다. 이 경우에는 .target입니다. 표적은 그 자체로는 많은 일을 하지 않지만 대신 다른 유닛을 그룹화하는 데 사용됩니다.

이것은 다른 init 시스템이 런레벨을 사용하는 것처럼 시스템을 특정 상태로 만들기 위해 사용할 수 있습니다. 특정 기능을 사용할 수 있는 경우 참조로 사용되어 해당 상태를 생성하는 데 필요한 개별 단위 대신 원하는 상태를 지정할 수 있습니다.

예를 들어, 스왑을 사용할 준비가 되었음을 나타내는 데 사용되는 swap.target이 있습니다. 이 프로세스의 일부인 장치는 해당 구성에서 WantedBy= 또는 RequiredBy= swap.target임을 표시하여 이 대상과 동기화할 수 있습니다. . 교체를 사용할 수 있어야 하는 장치는 Wants=, Requires= 및 After= 사양을 사용하여 이 조건을 지정하여 해당 장치의 특성을 나타낼 수 있습니다. 관계.

기본 대상 가져오기 및 설정

systemd 프로세스에는 시스템을 부팅할 때 사용하는 기본 대상이 있습니다. 해당 단일 대상에서 연속적인 종속성을 충족하면 시스템이 원하는 상태가 됩니다. 시스템의 기본 대상을 찾으려면 다음을 입력하십시오.

systemctl get-default

Outputmulti-user.target

다른 기본 대상을 설정하려면 set-default를 사용할 수 있습니다. 예를 들어 그래픽 데스크톱이 설치되어 있고 시스템이 기본적으로 해당 데스크톱으로 부팅되도록 하려면 그에 따라 기본 대상을 변경할 수 있습니다.

sudo systemctl set-default graphical.target

사용 가능한 대상 나열

다음을 입력하여 시스템에서 사용 가능한 대상 목록을 얻을 수 있습니다.

systemctl list-unit-files --type=target

런레벨과 달리 여러 대상이 한 번에 활성화될 수 있습니다. 활성 대상은 systemd가 대상에 연결된 모든 유닛을 시작하려고 시도했으며 다시 분해하려고 시도하지 않았음을 나타냅니다. 활성 대상을 모두 보려면 다음을 입력하십시오.

systemctl list-units --type=target

대상 격리

대상과 연결된 모든 장치를 시작하고 종속성 트리의 일부가 아닌 모든 장치를 중지할 수 있습니다. 이 작업을 수행하는 데 필요한 명령은 적절하게 isolate라고 합니다. 이는 다른 초기화 시스템에서 런레벨을 변경하는 것과 유사합니다.

예를 들어 graphical.target이 활성화된 그래픽 환경에서 작업하는 경우 그래픽 시스템을 종료하고 multi를 격리하여 시스템을 다중 사용자 명령줄 상태로 전환할 수 있습니다. -사용자.대상. graphical.target은 multi-user.target에 의존하지만 그 반대는 아니기 때문에 모든 그래픽 단위가 중지됩니다.

중요한 서비스를 중지하지 않도록 하기 위해 이 절차를 수행하기 전에 격리하려는 대상의 종속성을 살펴볼 수 있습니다.

systemctl list-dependencies multi-user.target

유지될 유닛에 만족하면 다음을 입력하여 대상을 격리할 수 있습니다.

sudo systemctl isolate multi-user.target

중요한 이벤트에 대한 바로 가기 사용

전원 끄기 또는 재부팅과 같은 중요한 이벤트에 대해 정의된 대상이 있습니다. 그러나 systemctl에는 약간의 추가 기능을 추가하는 단축키도 있습니다.

예를 들어 시스템을 복구(단일 사용자) 모드로 전환하려면 isolate rescue.target 대신 rescue 명령을 사용할 수 있습니다.

sudo systemctl rescue

이렇게 하면 로그인한 모든 사용자에게 이벤트에 대해 알리는 추가 기능이 제공됩니다.

시스템을 중지하려면 halt 명령을 사용할 수 있습니다.

sudo systemctl halt

전체 종료를 시작하려면 poweroff 명령을 사용할 수 있습니다.

sudo systemctl poweroff

재시작은 reboot 명령으로 시작할 수 있습니다.

sudo systemctl reboot

이러한 모든 경고는 로그인한 사용자에게 이벤트가 발생하고 있음을 경고합니다. 대상을 실행하거나 격리하는 것만으로는 수행되지 않습니다. 대부분의 기계는 systemd와 제대로 작동하도록 이러한 작업에 대해 더 짧고 더 일반적인 명령을 연결합니다.

예를 들어 시스템을 재부팅하려면 일반적으로 다음을 입력합니다.

sudo reboot

결론

이제 systemd 인스턴스와 상호 작용하고 제어할 수 있는 systemctl 명령의 일부 기본 기능에 익숙해졌을 것입니다. systemctl 유틸리티는 서비스 및 시스템 상태 관리를 위한 주요 상호 작용 지점이 됩니다.

systemctl은 주로 핵심 systemd 프로세스와 함께 작동하지만 systemd 생태계에는 다른 유틸리티에 의해 제어되는 다른 구성 요소가 있습니다. 로그 관리 및 사용자 세션과 같은 기타 기능은 별도의 데몬 및 관리 유틸리티(journald/journalctl 및 logind/loginctl 각각). 시간을 들여 다른 도구와 데몬에 익숙해지면 관리 작업이 더 쉬워집니다.