systemctl 명령어 정리 — 실무에서 자주 쓰는 예제와 팁

systemctl 명령어 정리 — 실무에서 자주 쓰는 예제와 팁

systemd 기반 리눅스에서 서비스·유닛을 관리하는 systemctl 명령어를 초보도 바로 써먹을 수 있게 정리했습니다. 기본 개념 → 유닛 파일 구조 → 자주 쓰는 명령어 예제 → 문제 해결 팁까지 한 번에.

목차

1. systemctl 개요
2. 유닛(Unit) 종류와 기본 구조
3. 자주 쓰는 명령어 모음(예제 포함)
4. 트러블슈팅 & 로그 확인
5. 권한·보안 관련 팁
6. 요약 & 실전 팁

 

1. systemctl 개요

systemd의 서비스 관리 도구로, 시스템 부팅 시 데몬(서비스)을 제어하고 유닛(unit)을 관리합니다. 전통적인 init 스크립트(/etc/init.d) 대신 사용되며, 서비스 시작/중지, 부팅 시 자동 시작 설정, 상태 확인, 유닛 파일 편집 등을 수행합니다.

기본 형식: systemctl [command] [unit]

 

2. 유닛(Unit) 종류와 기본 구조

• .service — 서비스 단위(데몬)
• .socket — 소켓 기반 활성화
• .target — 타겟(런레벨 비슷한 개념)
• .timer — 타이머(크론 대체 가능)
• .mount / .automount / .swap / .path — 마운트·스왑·경로 관련

유닛 파일 위치:

• /etc/systemd/system/ — 시스템 관리자(운영자) 정의 유닛
• /lib/systemd/system/ 또는 /usr/lib/systemd/system/ — 패키지 제공 유닛
• ~/.config/systemd/user/ — 사용자 단위 유닛

간단한 유닛 파일 예시 (/etc/systemd/system/myapp.service)

[Unit]
Description=MyApp Service
After=network.target

[Service]
Type=simple
User=appuser
ExecStart=/usr/local/bin/myapp --config /etc/myapp/config.yml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
      

 

3. 자주 쓰는 명령어 모음 (예제)

서비스 제어

sudo systemctl start myapp.service — 서비스 시작

sudo systemctl stop myapp.service — 서비스 중지

sudo systemctl restart myapp.service — 재시작

sudo systemctl reload myapp.service — 설정 재적용(지원할 때)

sudo systemctl status myapp.service — 상태 확인 (로그 일부 포함)

부팅 시 자동 시작 설정

sudo systemctl enable myapp.service — 부팅 시 자동 시작

sudo systemctl disable myapp.service — 자동 시작 해제

sudo systemctl is-enabled myapp.service — enable 상태 확인

유닛 파일 관련

sudo systemctl daemon-reload — 유닛 파일 변경 후 데몬 재로딩

sudo systemctl edit --full myapp.service — 전체 유닛 편집(편집기 열기)

sudo systemctl cat myapp.service — 유닛 파일 내용 출력

조회/리스트

systemctl list-units --type=service — 현재 활성(loaded & active) 서비스 목록

systemctl list-unit-files --type=service — 설치된 서비스 유닛 파일 목록 (enable/disable 상태 포함)

systemctl list-timers — 활성화된 timer 목록

보호/비활성화(마스크) 및 재설정

sudo systemctl mask myapp.service — 서비스 완전 비활성(시작 금지)

sudo systemctl unmask myapp.service — mask 해제

sudo systemctl reset-failed — 실패 상태 초기화

 

4. 트러블슈팅 & 로그 확인

서비스가 기동되지 않거나 빠르게 죽을 때는 journalctl로 로그를 확인하세요.

sudo journalctl -u myapp.service -b — 부팅 이후 해당 유닛 로그

sudo journalctl -u myapp.service --since "2025-01-01" --until "2025-01-02" — 기간 지정

sudo journalctl -f -u myapp.service — 실시간 로그 팔로우

유닛이 바로 죽는다면:

1. journalctl -u 로 stderr/stdout 메시지 확인
2. 유닛 파일의 ExecStart 경로·권한 확인
3. 환경변수/작업 디렉토리(WorkingDirectory)가 정확한지 확인
4. 의존 유닛(After=)이 제대로 실행되는지 체크

 

5. 권한·보안 관련 팁

• sudo 사용: 대부분 systemctl 명령은 root 권한 필요(또는 polkit 설정). 스크립트 내에서 root 없이 실행하려면 user unit( --user ) 고려.
• User 단위 유닛: 시스템 전체 권한이 필요 없는 프로세스는 systemctl --user로 관리.
• 서비스 계정 최소 권한: User= 를 지정해 루트 권한을 최소화. 파일/디렉토리 권한도 일치시킬 것.
• 환경 변수 유출 주의: ExecStart에 비밀번호 등 민감 값을 직접 넣지 마세요. systemd 환경파일(Directory=) 또는 외부 시크릿 매니저 사용 권장.

 

6. 요약 & 실전 팁

1. 유닛 변경 후 반드시 sudo systemctl daemon-reload 실행.
2. 서비스 재기동 시 먼저 status와 journalctl -u로 이유를 확인 후 재시작.
3. 트랜잭션성 작업은 프로세스 내에서 직접 처리하고, systemd는 프로세스 죽음·재시작 제어에 집중.
4. 운영 팁: 서비스는 Restart=on-failure로 재시작 정책을 주되, 무한 루프 방지용 StartLimitBurst/StartLimitIntervalSec 설정 고려.

빠른 치트시트

시작/중지/재시작: start/stop/restart · 상태: status · 로그: journalctl -u

더 필요한 내용 있나요? 댓글로 요청 주시면 특정 유닛 파일을 예로 들어 맞춤 유닛 파일을 만들어 드리거나, 배포·모니터링 관점에서 최적 설정을 제안해 드릴게요.