systemd와 systemctl을 활용한 서비스 관리

리눅스에서 데몬(서비스)을 관리하는 방식은 예전에는 init.d를 사용했지만, 최근 대부분 리눅스 배포판(Ubuntu, CentOS, Rocky 등)은 systemd 기반으로 전환되었습니다. systemd를 알아보기 전에 예전에 사용했던 init.d를 먼저 알아보겠습니다.

init.d란 무엇인가?

init.d는 리눅스에서 부팅 시 실행되는 서비스(데몬)를 관리하기 위한 디렉터리이며, SysV Init (System V initialzaion)방식의 일환입니다. init 시스템은 가장 먼저 실행되는 프로세스 (PID 1)로, 시스템을 초기화하고 서비스들을 단계별로 실행하는 역할을 합니다.

즉, init.d는 리눅스 시스템이 부팅될 때 어떤 서비스를 어떤 순서로 실행할지 정의하는 구조 중 하나입니다.

 

위치와 구조

- init.d 스크립트는 보통 /etc/init.d/ 디렉터리에 위치합니다.

- 이 안에는 서비스마다 하나씩 쉘 스크립트 파일이 있습니다.

모두 쉘 스크립트 파일로 구성되어 cat 명령어를 치면 스크립트 파일의 내용을 볼 수 있습니다.

예시

sudo /etc/init.d/apache2 start
sudo /etc/init.d/apache2 stop

 

작동 방식

1. /etc/init.d/ 안의 스크립트들은 모두 실행 가능한 쉘 스크립트입니다.

2. /etc/rc.d 또는 /etc/rc{runlevel].d/ 디렉터리에서 각 런레벨에 따라 필요한 스크립트를 링크해 실행합니다.

3. 런레벨(runlevel)에 따라 어떤 서비스를 시작할지 결정합니다.

 

런레벨 예시 (SysV 기준)

Runlevel	의미
0	시스템 종료 (halt)
1	단일 사용자 모드
3	멀티유저 (CLI)
5	멀티유저 + GUI
6	재부팅 (reboot)

 

왜 systemd가 생기고 사용할까?

기존 init.d 방식은 다음과 같은 한계가 있습니다.

- 병령 처리 불가 : 서비스가 순차적으로 실행되어 부팅 시간이 느림

- 종속성 관리 미흡 : 서비스 간 의존성을 세밀하게 지정하기 어려움

- 상태 추적 부족 : 서비스의 상태 확인이 제한적

이러한 문제를 개선하기 위해 systemd가 등장하였고, 이제는 대부분의 리눅스 배포판에서 init.d 대신 systemd를 사용합니다.

 

systemd를 사용하는데도 init.d가 왜 있을까??

/etc/init.d/ 디렉토리가 존재하는 이유는 하위 호환성(Backward Compatiblity) 때문입니다.

init.d는 legacy 방식이지만, 아직도 일부 스크립트나 패키지들이 이를 기반으로 동작하기 때문에 systemd에서도 계속 지원하고 있는 것입니다.

 

1. 하위 호환성이란??

 예전 리눅스에서 개발된 많은 서비스나 소프트웨어는 init.d 방식의 스크립트를 제공합니다. 이런 서비스들을 systemd 환경에서도 그대로 실행할 수 있도록 systemd는 /etc/init.d/를 인식할 수 있게 유지합니다.

 

2. 이식성과 표준화 부족

 모든 패키지나 개발자가 .service 유닛 파일을 제공하는 건 아닙니다. 특히 오래된 소프트웨어나 서버용 스크립트는 여전히 init 스크립트만 제공합니다.

 

3. 유지보수 및 마이그레이션 중인 시스템

 대규모 서버 환경에서는 전체를 systemd로 마이그레이션하는 데 시간이 걸립니다. 일부는 init.d와 systemd를 혼용하기도 하며, 완전히 대체하지 않고 공존시키는 전략을 택합니다.

 

systemd에서 init.d 스크립트 사용하는 방법

sudo /etc/init.d/apache2 start  # 직접 실행
# 또는
sudo systemctl start apache2    # systemd가 자동으로 init 스크립트를 감싸서 실행

 

systemd 기본 개념

- Unit(유닛) : systemd에서 관리하는 구성 요소 (서비스, 소켓, 마운트 등) (After=, Requires= 등)

- Service Unit : .service 확장자를 가지며, 데몬(서비스)을 관리하는 단위 (ExecStart=, Restart=, PIDFile= 등)

- Target Unit : runlevel 대체 개념으로, 부팅 상태를 지정 (WantedBy= )

 

systemctl 기본 명령어

systemctl status nginx	# 서비스 상태 확인
systemctl start nginx	# 서비스 시작
systemctl stop nginx	# 서비스 재시작
systemctl reload nginx	# 서비스 재로드 (설정 변경 반영)

 

부팅 시 자동 시작 설정

systemctl enable nginx	# 부팅 시 자동 시작
systemctl disable nginx	# 부팅 시 자동 시작 해제
systemctl is-enabled nginx # 현재 상태 확인

 

일시적으로 자동 시작 비활성화 

systemctl mask nginx	# 수동으로도 시작 못하게 막음
systemctl umask nginx 	# 다시 허용

 

서비스 유닛 파일 구조

서비스 유닛 파일은 보통 아래 위치에 있습니다.

- /etc/systemd/system/  사용자 정의 서비스

- /lib/systemcd/system/  시스템 서비스

sshd.service 파일

 

유닛 추가 시 명령어

sudo systemctl daemon-reexec      # systemd 자체 재시작
sudo systemctl daemon-reload      # 유닛 파일 변경 사항 반영
sudo systemctl start myapp
sudo systemctl enable myapp

 

명령어 정리 !! 

명령어	설명
systemctl start [서비스명]	서비스 시작
systemctl stop [서비스명]	서비스 중지
systemctl restart [서비스명]	서비스 재시작
systemctl reload [서비스명]	설정만 다시 읽기
systemctl enable [서비스명]	부팅 시 자동 실행 설정
systemctl status [서비스명]	서비스 상태 확인
systemctl list-units --type=service	현재 실행 중인 서비스 목록
journalctl -u [서비스명]	서비스 로그 확인

 

마지막으로..

systemd는 단순한 서비스 매니저가 아니라 리눅스의 핵심 컴포넌트입니다.

systemctl 명령어를 익히면 서비스 관리, 디버깅, 자동화 작업에 있어 큰 도움이 됩니다.