소개
이 실습에서는 systemctl 명령어를 사용하여 RHEL에서 시스템 서비스를 관리하는 실무 경험을 쌓습니다. 로드된 모든 활성 서비스를 확인하고, 특정 서비스의 상태를 점검하며, 시작, 중지, 재시작을 통해 런타임 동작을 제어하는 방법을 배웁니다. 또한 서비스 구성을 다시 로드하고, 부팅 시 자동 시작을 위해 서비스를 활성화하거나 비활성화하는 방법, 그리고 서비스 활성화를 방지하기 위한 마스킹(masking) 및 언마스킹(unmasking)의 고급 개념을 학습합니다.
이 실습 가이드는 RHEL 시스템 운영에 필수적인 서비스 수명 주기를 효과적으로 모니터링하고 관리할 수 있는 핵심 기술을 제공합니다.
systemctl을 사용하여 로드된 모든 활성 서비스 보기
이 단계에서는 systemctl 명령어를 사용하여 자동으로 시작된 시스템 프로세스를 식별하는 방법을 배웁니다. systemctl은 Red Hat Enterprise Linux에서 systemd 서비스를 관리하기 위한 기본 도구입니다.
먼저, 현재 로드되어 활성화된 모든 서비스 유닛을 나열하는 방법을 살펴보겠습니다. 이를 위해 systemctl list-units --type=service 명령어를 사용합니다. 이 명령어는 systemd 데몬이 성공적으로 구문 분석하여 메모리에 로드했고, 현재 활성 상태인 서비스 유닛을 표시합니다.
RHEL 환경에서 터미널을 엽니다. 이미 labex 사용자로 로그인되어 있으며, 현재 디렉토리는 ~/project입니다.
다음 명령어를 실행하여 로드된 모든 활성 서비스 유닛을 나열합니다.
systemctl list-units --type=service
다양한 서비스와 그 상태를 보여주는 다음과 유사한 출력을 볼 수 있습니다.
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing Service
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
...output omitted...
출력의 각 열을 살펴보겠습니다.
- UNIT: 서비스 유닛의 이름으로, 일반적으로
.service로 끝납니다. - LOAD:
systemd데몬이 유닛의 구성을 성공적으로 구문 분석하여 메모리에 로드했는지 여부를 나타냅니다.loaded는 성공했음을 의미합니다. - ACTIVE: 유닛의 상위 수준 활성화 상태입니다.
active는 일반적으로 유닛이 성공적으로 시작되었음을 의미합니다. - SUB: 더 자세한 정보를 제공하는 하위 수준 활성화 상태입니다. 실행 중인 서비스의 경우
running이 일반적입니다. - DESCRIPTION: 서비스가 수행하는 작업에 대한 간략한 설명입니다.
q를 눌러 명령어를 종료합니다.
다음으로, systemctl list-units --type=service와 함께 --all 옵션을 사용하면 활성화 상태(활성, 비활성, 실패 등)에 관계없이 모든 서비스 유닛을 나열할 수 있습니다. 이는 설치되어 있지만 현재 실행 중이지 않은 서비스를 확인하는 데 유용합니다.
다음 명령어를 실행합니다.
systemctl list-units --type=service --all
출력에는 inactive 상태이거나 다른 상태인 서비스가 포함되어 더 포괄적인 보기를 제공합니다.
UNIT LOAD ACTIVE SUB DESCRIPTION
atd.service loaded active running Job spooling tools
auditd.service loaded active running Security Auditing ...
auth-rpcgss-module.service loaded inactive dead Kernel Module ...
chronyd.service loaded active running NTP client/server
cpupower.service loaded inactive dead Configure CPU power ...
crond.service loaded active running Command Scheduler
dbus-broker.service loaded active running D-Bus System Message Bus
● display-manager.service not-found inactive dead display-manager.service
...output omitted...
마지막으로, 로드되지 않았거나 활성화되지 않은 파일을 포함하여 모든 설치된 유닛 파일을 확인하려면 systemctl list-unit-files --type=service를 사용할 수 있습니다. 이 명령어는 서비스가 enabled(부팅 시 시작), disabled(부팅 시 시작 안 함), static(직접 활성화할 수 없으나 다른 유닛에 의해 시작될 수 있음), 또는 masked(시작 방지됨) 상태인지 보여줍니다.
다음 명령어를 실행합니다.
systemctl list-unit-files --type=service
각 서비스 유닛 파일의 STATE 및 VENDOR PRESET을 나타내는 다음과 유사한 출력을 볼 수 있습니다.
UNIT FILE STATE VENDOR PRESET
arp-ethers.service disabled disabled
atd.service enabled enabled
auditd.service enabled enabled
auth-rpcgss-module.service static -
autovt@.service alias -
blk-availability.service disabled disabled
...output omitted...
이 명령어는 시스템 부팅 시 자동으로 시작되도록 구성된 서비스를 파악하는 데 특히 유용합니다.
systemctl status를 사용하여 특정 서비스의 상태 확인
이 단계에서는 systemctl status 명령어를 사용하여 특정 서비스의 상세 상태를 확인하는 방법을 배웁니다. 이 명령어는 서비스가 실행 중인지 여부, 프로세스 ID, 메모리 사용량, 최근 로그 항목 등 서비스에 대한 포괄적인 정보를 제공합니다.
예시로 crond.service(cron 데몬)를 사용하겠습니다. cron 데몬은 예약된 작업을 처리하는 일반적인 서비스입니다.
RHEL 환경에서 터미널을 엽니다. ~/project 디렉토리에 있는지 확인하십시오.
다음 명령어를 실행하여 crond.service의 상태를 확인합니다.
systemctl status crond.service
다음과 유사한 상세 출력을 볼 수 있습니다.
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; preset: enabled)
Active: active (running) since Mon 2022-03-14 05:38:10 EDT; 25min ago
Main PID: 1089 (crond)
Tasks: 1 (limit: 35578)
Memory: 1.2M
CPU: 12ms
CGroup: /system.slice/crond.service
└─1089 /usr/sbin/crond -n
Mar 14 05:38:10 workstation systemd[1]: Started Command Scheduler.
Warning: some journal files were not opened due to insufficient permissions.
출력의 주요 필드를 살펴보겠습니다.
Loaded: 이 줄은 서비스 유닛의 구성 파일이 처리되었는지 알려줍니다. 또한 유닛 파일의 경로(/usr/lib/systemd/system/crond.service)와 활성화 상태(enabled는 부팅 시 시작되도록 구성되었음을 의미)를 보여줍니다.Active: 매우 중요합니다. 서비스의 현재 상태를 나타냅니다.active (running)은 서비스가 현재 활성 상태이며 프로세스가 실행 중임을 의미합니다. 또한 활성 상태가 지속된 시간도 보여줍니다. 다른 상태로는inactive(실행 안 됨),active (exited)(일회성 작업 완료),failed(오류 발생)가 있을 수 있습니다.Main PID: 서비스와 관련된 메인 프로세스의 프로세스 ID(PID)와 명령어 이름입니다.Tasks: 서비스가 현재 사용 중인 작업(스레드) 수입니다.Memory: 서비스가 소비하는 메모리 양입니다.CPU: 서비스가 소비한 CPU 시간입니다.CGroup: 리소스 관리에 사용되는 서비스가 속한 제어 그룹에 대한 정보입니다.CGroup아래의 줄은 서비스와 관련된 최근 로그 항목을 보여주며, 시작 및 진행 중인 활동에 대한 통찰력을 제공합니다.
systemctl status 외에도 서비스 상태의 특정 측면을 빠르게 확인하기 위한 더 간단한 명령어들이 있습니다.
서비스가 활성 상태인지 확인하려면:
systemctl is-active crond.service예상 출력:
active서비스가 활성화(부팅 시 시작되도록 구성)되었는지 확인하려면:
systemctl is-enabled crond.service예상 출력:
enabled서비스가 실패했는지 확인하려면:
systemctl is-failed crond.service예상 출력(정상 실행 시):
active서비스 시작이나 실행에 문제가 있었다면 이 명령어는
failed를 반환합니다.
이 명령어들은 systemctl status의 전체 상세 출력이 필요하지 않을 때 스크립팅이나 빠른 확인을 위해 유용합니다.
systemctl을 사용하여 서비스 시작, 중지 및 재시작
이 단계에서는 systemctl 명령어를 사용하여 시스템 서비스의 수명 주기를 관리하는 방법을 배웁니다. 서비스를 시작, 중지 및 재시작하는 연습을 할 것입니다. 이 연습을 위해 직접 생성할 더미 서비스를 사용하겠습니다. 이 접근 방식은 중요한 시스템 기능에 영향을 주지 않고 안전하게 서비스를 조작할 수 있도록 보장합니다.
먼저 간단한 서비스 유닛 파일을 생성해 보겠습니다. 이 파일은 몇 초마다 로그 파일에 타임스탬프를 기록하는 서비스를 정의합니다.
nano를 사용하여 systemd 시스템 디렉토리에 mytest.service라는 새 서비스 유닛 파일을 직접 생성합니다.
sudo nano /etc/systemd/system/mytest.service
nano 편집기에 다음 내용을 붙여넣습니다.
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service is running." >> /tmp/mytest.log; sleep 5; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
[Unit]: 유닛에 대한 일반 정보를 포함합니다.Description은 사람이 읽을 수 있는 이름을 제공하며,After=network.target은 이 서비스가 네트워크가 연결된 후에 시작되어야 함을 지정합니다.[Service]: 서비스의 동작을 정의합니다.Type=simple:ExecStart명령어가 메인 프로세스인 간단한 서비스 유형을 나타냅니다.ExecStart: 서비스가 시작될 때 실행할 명령어입니다. 여기서는 5초마다/tmp/mytest.log에 타임스탬프가 찍힌 메시지를 기록하는 bash 루프입니다.ExecStop: 서비스가 중지될 때 실행할 명령어입니다. 로그에 중지 메시지를 기록합니다.Restart=on-failure: 0이 아닌 상태로 종료될 경우 서비스를 재시작하도록 구성합니다.
[Install]: 서비스 설치 방법에 대한 정보를 포함합니다.WantedBy=multi-user.target은 시스템이 다중 사용자 런레벨에 도달했을 때 이 서비스가 시작되어야 함을 의미합니다.
Ctrl+X를 누르고 Y를 눌러 확인한 다음, Enter를 눌러 파일을 저장합니다.
이제 systemd 데몬을 다시 로드하여 새 서비스 파일을 인식하도록 합니다.
sudo systemctl daemon-reload
서비스 시작
서비스를 시작하려면 systemctl start 명령어를 사용합니다.
mytest.service를 시작하려면 다음 명령어를 실행합니다. systemctl 작업은 일반적으로 루트 권한이 필요하므로 sudo를 사용해야 합니다.
sudo systemctl start mytest.service
명령어가 성공하면 즉각적인 출력은 없습니다.
이제 상태를 확인하여 서비스가 실행 중인지 검증합니다.
systemctl status mytest.service
서비스가 active (running) 상태임을 나타내는 출력이 표시되어야 합니다.
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
로그 파일을 확인하여 서비스가 메시지를 기록하고 있는지 확인할 수도 있습니다.
tail -f /tmp/mytest.log
다음과 같이 5초마다 새로운 줄이 나타나는 것을 볼 수 있습니다.
Tue Jul 22 09:15:09 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:14 AM CST 2025: My Test Service is running.
Ctrl+C를 눌러 tail을 종료합니다.
서비스 중지
실행 중인 서비스를 중지하려면 systemctl stop 명령어를 사용합니다.
mytest.service를 중지하려면 다음 명령어를 실행합니다.
sudo systemctl stop mytest.service
마찬가지로 즉각적인 출력은 없습니다.
서비스가 중지되었는지 확인합니다.
systemctl status mytest.service
이제 출력에 Active: inactive (dead)가 표시되어야 합니다.
○ mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: inactive (dead) since ...
...output omitted...
로그 파일 /tmp/mytest.log를 다시 확인합니다. "My Test Service stopped." 메시지가 보이고 새로운 "running" 메시지는 나타나지 않아야 합니다.
tail /tmp/mytest.log
출력은 다음과 유사합니다.
Tue Jul 22 09:15:24 AM CST 2025: My Test Service is running.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
서비스 재시작
서비스를 재시작하려면 systemctl restart 명령어를 사용합니다. 이 명령어는 먼저 서비스를 중지한 다음 다시 시작합니다. 이는 서비스 구성을 변경하고 변경 사항을 적용해야 할 때 유용합니다.
mytest.service를 재시작하려면 다음 명령어를 실행합니다.
sudo systemctl restart mytest.service
서비스가 다시 실행 중인지 확인합니다.
systemctl status mytest.service
Active: active (running)이 다시 표시되어야 하며, Main PID는 새로운 프로세스가 시작되었음을 나타내는 새로운 번호일 가능성이 높습니다.
● mytest.service - My Test Service
Loaded: loaded (/etc/systemd/system/mytest.service; disabled; preset: disabled)
Active: active (running) since ...
Main PID: ... (bash)
Tasks: 2 (limit: ...)
Memory: ...
CPU: ...
CGroup: /system.slice/mytest.service
├─... /bin/bash -c "while true; do echo \"\$(date): My Test Service is running.\" >> /tmp/mytest.log; sleep 5; done"
└─... sleep 5
...output omitted...
로그 파일 /tmp/mytest.log를 확인하여 서비스가 "running" 메시지 기록을 재개했는지 확인합니다.
tail -f /tmp/mytest.log
"stopped" 메시지 뒤에 새로운 "running" 메시지가 표시되어야 합니다.
Tue Jul 22 09:15:28 AM CST 2025: My Test Service stopped.
Tue Jul 22 09:15:40 AM CST 2025: My Test Service is running.
Ctrl+C를 눌러 tail을 종료합니다.
서비스에 구성 변경 사항 적용
이 단계에서는 서비스 구성을 다시 로드하는 방법에 대해 배웁니다. 일부 서비스는 전체 재시작 없이 구성 파일의 변경 사항을 적용할 수 있습니다. 이를 서비스 "다시 로드(reloading)"라고 합니다. 다시 로드는 서비스 중단을 방지하고 기존 연결이나 상태를 유지하므로 일반적으로 재시작보다 선호됩니다. 서비스가 다시 로드될 때, PID가 변경되는 전체 재시작과 달리 프로세스 ID(PID)는 일반적으로 동일하게 유지됩니다.
이전 단계에서 사용한 mytest.service를 계속 사용하겠습니다. 동작을 수정하고 다시 로드하여 어떤 일이 발생하는지 확인해 보겠습니다.
먼저 mytest.service가 실행 중인지 확인합니다. 실행 중이 아니라면 시작하십시오.
sudo systemctl start mytest.service
상태를 확인하고 Main PID를 기록해 둡니다.
systemctl status mytest.service
이제 mytest.service 파일을 수정하여 기록하는 메시지와 간격을 변경해 보겠습니다. 로그 메시지와 sleep 시간을 변경합니다.
nano로 /etc/systemd/system/mytest.service를 엽니다.
sudo nano /etc/systemd/system/mytest.service
ExecStart 줄을 다음과 같이 변경하여 메시지를 수정하고 sleep 시간을 5에서 2초로 변경합니다.
[Unit]
Description=My Test Service
After=network.target
[Service]
Type=simple
ExecStart=/bin/bash -c 'while true; do echo "$(date): My Test Service (reloaded) is running." >> /tmp/mytest.log; sleep 2; done'
ExecStop=/bin/bash -c 'echo "$(date): My Test Service stopped." >> /tmp/mytest.log'
Restart=on-failure
[Install]
WantedBy=multi-user.target
Ctrl+X, Y, Enter를 눌러 파일을 저장합니다.
변경 사항을 저장한 후, systemd에 서비스 구성이 변경되었음을 알려야 합니다.
sudo systemctl daemon-reload
이제 서비스를 다시 로드하여 변경 사항을 적용해 보겠습니다.
sudo systemctl reload mytest.service
아마도 오류가 발생할 것입니다.
Failed to reload mytest.service: Job type reload is not applicable for unit mytest.service.
이 오류는 우리의 간단한 서비스가 다시 로드 요청을 처리하도록 구성되지 않았기 때문에 발생합니다. 서비스가 다시 로드 가능하려면 유닛 파일에 구성을 다시 로드하기 위해 실행할 명령어를 지정하는 ExecReload 지시문이 포함되어야 합니다. mytest.service에는 이것이 없기 때문에 systemd는 이를 다시 로드하는 방법을 모릅니다.
이런 상황에서 systemd는 편리한 명령어인 reload-or-restart를 제공합니다. 이 명령어는 서비스를 다시 로드하려고 시도하지만, 다시 로드가 지원되지 않으면 서비스 재시작으로 대체합니다. 이는 구성 변경 사항을 적용하는 더 안전하고 효과적인 방법인 경우가 많습니다.
이제 reload-or-restart를 사용해 보겠습니다.
sudo systemctl reload-or-restart mytest.service
이 명령어는 성공할 것입니다. 이제 서비스 상태를 다시 확인합니다.
systemctl status mytest.service
Main PID를 관찰하십시오. 서비스가 재시작되었기 때문에(다시 로드할 수 없었으므로), Main PID가 새로운 번호임을 알 수 있습니다. 이는 이전 프로세스가 중지되고 업데이트된 구성으로 새 프로세스가 시작되었음을 확인해 줍니다.
마지막으로 /tmp/mytest.log 파일을 확인하여 변경 사항이 적용되었는지 확인합니다.
tail -f /tmp/mytest.log
2초마다 "My Test Service (reloaded) is running."이라는 새로운 로그 메시지가 나타나는 것을 볼 수 있습니다. Ctrl+C를 눌러 tail을 종료합니다.
systemctl을 사용하여 부팅 시 서비스 활성화 및 비활성화
이 단계에서는 부팅 시 서비스가 자동으로 시작되도록 구성(활성화)하거나 부팅 시 시작되지 않도록 방지(비활성화)하는 방법을 배웁니다. 이는 시스템 리소스를 관리하고 시스템이 시작될 때 필요한 서비스를 사용할 수 있도록 보장하는 데 중요합니다.
일반적인 systemd 환경에서 서비스를 활성화하면 서비스의 유닛 파일을 가리키는 적절한 systemd 구성 디렉토리(예: /etc/systemd/system/multi-user.target.wants/)에 심볼릭 링크가 생성됩니다. 서비스를 비활성화하면 이러한 링크가 제거됩니다.
systemd가 전통적인 의미에서 완전히 작동하지 않을 수 있는 컨테이너화된 환경에 있으므로, enable 및 disable 명령어가 컨테이너 재시작 시에도 유지되는 /etc/systemd/system 디렉토리에 실제 심볼릭 링크를 생성하지 않을 수 있습니다. 그러나 systemctl은 여전히 이러한 명령어를 처리하고 내부 상태를 업데이트하며, 우리는 이것을 관찰할 것입니다.
이 시연을 위해 mytest.service를 계속 사용하겠습니다.
먼저 이전 단계에서 mytest.service가 중지되었는지 확인합니다.
sudo systemctl stop mytest.service
서비스 활성화
서비스를 활성화하려면 systemctl enable 명령어를 사용합니다. 이 명령어는 시스템이 부팅될 때 서비스가 자동으로 시작되도록 구성합니다.
mytest.service를 활성화하려면 다음 명령어를 실행합니다.
sudo systemctl enable mytest.service
전체 systemd 환경에서 심볼릭 링크가 생성되었음을 나타내는 다음과 유사한 출력을 볼 수 있습니다.
Created symlink /etc/systemd/system/multi-user.target.wants/mytest.service → /etc/systemd/system/mytest.service.
이제 systemctl is-enabled를 사용하여 서비스가 활성화되었는지 확인합니다.
systemctl is-enabled mytest.service
예상 출력:
enabled
이는 systemctl이 이제 mytest.service를 부팅 시 활성화된 것으로 간주함을 확인해 줍니다.
--now 옵션을 사용하여 서비스 활성화와 시작을 하나의 명령어로 결합할 수도 있습니다. 이는 서비스가 즉시 실행되고 향후 부팅 시에도 시작되도록 구성하는 편리한 방법입니다.
먼저 --now 시연을 준비하기 위해 비활성화하겠습니다.
sudo systemctl disable mytest.service
이제 동시에 활성화하고 시작합니다.
sudo systemctl enable --now mytest.service
상태와 활성화 여부를 확인합니다.
systemctl status mytest.service
systemctl is-enabled mytest.service
status 명령어에서 Active: active (running)이, is-enabled 명령어에서 enabled가 표시되어야 합니다.
서비스 비활성화
서비스를 비활성화하려면 systemctl disable 명령어를 사용합니다. 이 명령어는 부팅 시 서비스가 시작되도록 하는 구성을 제거합니다.
mytest.service를 비활성화하려면 다음 명령어를 실행합니다.
sudo systemctl disable mytest.service
심볼릭 링크가 제거되었음을 나타내는 출력이 표시될 수 있습니다.
Removed /etc/systemd/system/multi-user.target.wants/mytest.service.
이제 서비스가 비활성화되었는지 확인합니다.
systemctl is-enabled mytest.service
예상 출력:
disabled
활성화와 마찬가지로 --now 옵션을 사용하여 서비스 비활성화와 중지를 결합할 수 있습니다. 이렇게 하면 서비스가 즉시 중지되고 향후 부팅 시 시작되지 않도록 방지됩니다.
sudo systemctl disable --now mytest.service
상태와 활성화 여부를 확인합니다.
systemctl status mytest.service
systemctl is-enabled mytest.service
status 명령어에서 Active: inactive (dead)가, is-enabled 명령어에서 disabled가 표시되어야 합니다.
이것으로 서비스 활성화 및 비활성화 시연을 마칩니다. 실제 systemd 환경에서는 이러한 명령어가 부팅 구성을 직접 조작한다는 점을 기억하십시오.
systemctl을 사용하여 서비스 마스킹 및 언마스킹
이 마지막 단계에서는 서비스 마스킹(masking) 및 언마스킹(unmasking)에 대해 배웁니다. 서비스를 마스킹하는 것은 수동으로든 부팅 시 자동으로든 서비스가 시작되는 것을 방지하는 강력한 방법입니다.
서비스를 마스킹하면 systemd는 /etc/systemd/system/<service-name>.service에서 /dev/null로 심볼릭 링크를 생성하여 서비스 유닛 파일을 systemd가 사용할 수 없게 만듭니다. 이는 disable보다 더 강력한 대안입니다.
이 메커니즘은 패키지가 서비스 파일을 설치하는 위치인 /usr/lib/systemd/system에 정의된 서비스에 가장 잘 작동합니다. mask 명령어는 /etc/systemd/system에 재정의하는 "빈" 파일을 생성합니다. 그러나 발견했듯이, /etc/systemd/system에 직접 생성한 서비스(예: mytest.service)를 마스킹하려고 하면 데이터 손실을 유발할 수 있는 기존 구성 파일을 덮어쓰지 않도록 설계되었기 때문에 명령어가 실패할 수 있습니다.
마스킹을 올바르게 시연하기 위해 기존 서비스인 atd.service를 사용하겠습니다.
먼저 atd.service의 현재 상태를 확인합니다. 활성 및 활성화 상태여야 합니다.
systemctl status atd.service
출력은 서비스가 활성 상태이며 실행 중임을 보여주는 다음과 유사합니다.
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:13:06 CST; 22min ago
Docs: man:atd(8)
Main PID: 1222 (atd)
Tasks: 1 (limit: 22509)
Memory: 900.0K
CPU: 5ms
CGroup: /system.slice/atd.service
└─1222 /usr/sbin/atd -f
서비스 마스킹
서비스를 마스킹하기 전에 중지하는 것이 좋습니다.
sudo systemctl stop atd.service
이제 다음 명령어를 실행하여 atd.service를 마스킹합니다.
sudo systemctl mask atd.service
/dev/null에 대한 심볼릭 링크가 생성되었음을 나타내는 출력이 표시됩니다.
Created symlink /etc/systemd/system/atd.service → /dev/null.
이제 마스킹된 서비스를 시작해 봅니다.
sudo systemctl start atd.service
서비스가 마스킹되었음을 나타내는 오류 메시지가 표시됩니다.
Failed to start atd.service: Unit atd.service is masked.
systemctl list-unit-files를 사용하여 서비스 상태를 확인할 수도 있습니다.
systemctl list-unit-files --type=service | grep atd.service | tee ~/project/atd-mask-state.txt
출력에서 atd.service에 대해 masked가 표시되어야 합니다.
atd.service masked enabled
이는 서비스가 이제 마스킹되어 시작할 수 없음을 확인해 줍니다.
서비스 언마스킹
서비스를 언마스킹하려면 systemctl unmask 명령어를 사용합니다. 이 명령어는 /dev/null에 대한 심볼릭 링크를 제거하여 /usr/lib/systemd/system에서 원래 서비스 파일을 복원합니다.
atd.service를 언마스킹하려면 다음 명령어를 실행합니다.
sudo systemctl unmask atd.service
심볼릭 링크가 제거되었음을 나타내는 출력이 표시됩니다.
Removed "/etc/systemd/system/atd.service".
언마스킹 후, unmask는 /dev/null 링크만 제거하고 서비스를 자동으로 재시작하지 않으므로 서비스를 다시 시작합니다.
sudo systemctl start atd.service
이제 서비스 상태를 확인합니다.
systemctl status atd.service
Active: active (running)이 표시되어야 합니다.
● atd.service - Deferred execution scheduler
Loaded: loaded (/usr/lib/systemd/system/atd.service; enabled; preset: enabled)
Active: active (running) since Tue 2025-07-22 09:36:10 CST; 2s ago
Docs: man:atd(8)
Main PID: 7372 (atd)
Tasks: 1 (limit: 22509)
Memory: 868.0K
CPU: 6ms
CGroup: /system.slice/atd.service
└─7372 /usr/sbin/atd -f
이것으로 서비스 및 데몬 제어 실습을 마칩니다. systemctl을 사용하여 서비스를 보고, 시작하고, 중지하고, 재시작하고, 다시 로드하고, 활성화하고, 비활성화하고, 마스킹하고, 언마스킹하는 방법을 배웠습니다.
요약
이 실습에서는 systemd가 기본 init 시스템이 아닐 수 있는 컨테이너화된 환경에서도 systemctl 명령어를 사용하여 제어 시스템 서비스를 관리하는 실무 경험을 쌓았습니다. systemctl list-units --type=service를 사용하여 로드된 모든 활성 서비스 유닛을 나열하는 방법을 배웠고, UNIT, LOAD, ACTIVE, SUB 열을 이해하여 서비스 상태를 해석하는 방법을 익혔습니다.
또한 systemctl status로 특정 서비스의 상태를 확인하고, 서비스를 시작, 중지, 재시작하여 서비스 수명 주기를 제어하는 필수 서비스 관리 작업을 살펴보았습니다. 서비스 구성을 다시 로드하는 방법, 부팅 시 동작을 제어하기 위해 서비스를 활성화 및 비활성화하는 방법, 그리고 서비스 시작을 방지하기 위한 마스킹 및 언마스킹의 고급 개념도 다루었습니다. 이 포괄적인 기술 세트는 RHEL 시스템에서 서비스를 관리하기 위한 탄탄한 기반을 제공합니다.
