WSL2에 systemd를 켠 뒤 서비스가 안 뜰 때, 상태 확인과 복구 순서

AI를 활용하여 생성한 이미지입니다.

WSL2에서 개발 서버나 데이터베이스를 띄우다 보면 systemctl을 쓰고 싶은 순간이 와요. 예전에는 WSL이 일반적인 Linux 부팅 과정을 거치지 않아 서비스 관리가 어색했지만, 현재 WSL2는 systemd를 사용할 수 있습니다.[1] 다만 설정 파일을 바꿨는데도 서비스가 시작되지 않거나, Windows를 재부팅한 뒤 다시 확인해야 하는 상황이 생겨요.

이 글은 WSL 설치법을 처음부터 설명하지 않아요. 이미 WSL2 배포판을 쓰고 있고, 그 안에서 Docker·PostgreSQL·Redis 같은 서비스를 관리하려는 분을 대상으로 합니다. 핵심은 systemctl start를 무작정 반복하는 게 아니라, WSL의 실행 상태와 systemd의 PID 1 여부를 분리해서 확인하는 데 있어요.

systemd를 켜면 무엇이 달라질까?

systemd는 Linux에서 PID 1로 실행되며 나머지 시스템과 서비스를 시작·관리하는 역할을 합니다.[1] WSL2에 systemd를 켜면 배포판 안에서 서비스 유닛을 등록하고, systemctl status와 systemctl list-unit-files --type=service로 상태를 확인할 수 있어요.[1]

여기서 Windows 서비스와 Linux 서비스를 섞어 생각하면 문제가 커집니다. WSL 안의 systemd는 해당 배포판 인스턴스 안에서만 동작하고, Windows가 켜졌다고 해서 모든 Linux 서비스가 계속 살아 있는 것은 아니에요. WSL 배포판이 종료되면 그 안의 프로세스도 함께 내려갑니다. 상시 서버가 필요하다면 WSL의 수명 관리와 서비스 자동 시작을 함께 설계해야 해요.

먼저 현재 WSL 상태부터 기록해요

PowerShell에서 다음 명령을 실행해 현재 기본 배포판과 커널 정보를 확인하세요. Microsoft도 일반 설정과 커널 버전을 확인할 때 wsl --status를 안내합니다.[2]

wsl --status
wsl --list --verbose

VERSION이 2인지 먼저 보세요. WSL 1 배포판에 systemd 설정을 넣어도 WSL2와 같은 방식으로 동작하지 않아요. 여러 배포판이 있다면 이후 명령의 대상이 어느 배포판인지도 정해야 합니다. 기본 배포판을 바꾸는 명령은 다음과 같아요.

wsl --set-default <DistributionName>

배포판 이름은 wsl --list --verbose의 출력값을 그대로 사용하세요. 이름을 추측해서 입력하면 다른 배포판을 확인하거나 오류를 만들 수 있습니다.

설정 파일은 배포판 안에서 바꿔요

WSL2 배포판 터미널에서 /etc/wsl.conf를 열고 다음 내용을 넣습니다. 파일이 이미 있다면 기존 항목을 지우지 말고 섹션과 키가 겹치는지 먼저 확인하세요.

[boot]
systemd=true

저장한 뒤에는 Linux 터미널의 종료만으로 충분하지 않을 수 있어요. PowerShell에서 모든 WSL 인스턴스를 종료하고 다시 시작해야 합니다. Microsoft의 절차도 설정 저장 후 wsl.exe --shutdown으로 WSL 인스턴스를 재시작하도록 안내합니다.[1]

wsl.exe --shutdown
wsl

이 명령은 실행 중인 WSL 배포판을 모두 내립니다. 저장하지 않은 작업이나 개발 서버의 미반영 데이터를 먼저 확인하세요. WSL은 다시 실행하면 배포판을 새로 설치하는 것이 아니라 기존 가상 디스크를 다시 여는 방식이라, --shutdown 자체가 배포판 삭제 명령은 아닙니다.

켜졌는지 확인하는 세 단계

배포판을 다시 연 뒤 아래 순서로 확인합니다.

1. ps -p 1 -o comm=을 실행해 PID 1의 프로세스 이름을 확인합니다. systemd가 정상적으로 올라왔다면 보통 systemd가 표시돼요.
2. systemctl is-system-running으로 systemd의 전체 상태를 봅니다. running이 아니더라도 부팅 중이거나 일부 유닛이 실패한 상태일 수 있으니 다음 단계로 넘어가세요.
3. systemctl --failed와 systemctl list-units --type=service --state=running으로 실패한 유닛과 실제 실행 중인 서비스를 나눠 봅니다.

ps -p 1 -o pid,comm,args
systemctl is-system-running
systemctl --failed
systemctl list-units --type=service --state=running

Microsoft도 재시작 뒤 systemctl status로 실행 상태를 확인하고, 서비스 유닛 목록을 조회하는 방법을 제시합니다.[1] systemctl status가 연결 오류를 내면 특정 서비스의 문제로 좁히기 전에 PID 1과 systemd 자체가 실행됐는지부터 확인하세요.

서비스 하나만 실패할 때 보는 순서

예를 들어 PostgreSQL이 실패했다고 가정해 볼게요. 배포판이나 설치 버전에 따라 유닛 이름은 달라질 수 있으므로 먼저 목록에서 정확한 이름을 찾습니다.

systemctl list-unit-files --type=service | grep -Ei 'postgres|redis|docker'
systemctl status <unit-name> --no-pager
journalctl -u <unit-name> -b --no-pager -n 100

세 명령의 역할은 다릅니다. 첫 줄은 등록된 서비스 파일을 찾고, 둘째 줄은 최근 상태와 종료 코드를 보여주며, 셋째 줄은 현재 부팅 시점의 로그를 뒤에서 100줄 읽습니다. “실행되지 않는다”는 결과만 보지 말고, 포트 충돌·권한·설정 파일 문법·데이터 디렉터리 권한 중 어디에서 멈췄는지 확인해야 해요.

설정 파일을 고친 뒤에는 다음처럼 실패 상태를 지우고 다시 시도할 수 있어요.

sudo systemctl reset-failed <unit-name>
sudo systemctl restart <unit-name>
sudo systemctl status <unit-name> --no-pager

그래도 실패한다면 restart를 계속 반복하지 마세요. 로그의 첫 번째 오류를 먼저 해결하는 편이 안전합니다. 특히 데이터베이스 서비스는 반복 재시작보다 설정 파일과 데이터 디렉터리의 소유자·권한을 확인하는 것이 우선이에요.

부팅할 때 자동 시작할 서비스 고르기

서비스를 설치했다고 자동 시작이 보장되지는 않습니다. 장시간 실행할 서비스만 enable 하세요.

sudo systemctl enable --now <unit-name>
systemctl is-enabled <unit-name>
systemctl is-active <unit-name>

enable은 다음 부팅 때 자동 시작하도록 연결을 만들고, --now는 지금 즉시 시작합니다. is-enabled와 is-active를 따로 확인하면 “자동 시작 설정”과 “현재 실행”을 헷갈리지 않아요. 개발 중 잠깐 쓰는 서비스라면 enable 없이 필요할 때만 start하는 편이 WSL 시작 시간을 줄일 수 있습니다.

자동 시작을 되돌리려면 다음처럼 합니다.

sudo systemctl disable --now <unit-name>

이 명령은 서비스 설정을 지울 뿐, 패키지와 데이터까지 삭제하지는 않아요. 완전히 제거해야 한다면 배포판과 패키지 관리자의 제거 절차를 별도로 검토해야 합니다.

WSL에서 자주 놓치는 실패 원인

특히 wsl --unregister는 대상 배포판의 데이터·설정·설치 소프트웨어를 영구적으로 제거하므로, Microsoft 문서도 주의를 요구합니다.[2] systemd 문제를 해결하려고 이 명령을 먼저 실행할 이유는 거의 없어요.

적용 전후에 남겨 둘 체크리스트

• wsl --list --verbose에서 대상 배포판이 WSL2인지 기록하세요.
• /etc/wsl.conf의 기존 설정을 백업한 뒤 [boot] 섹션을 추가하세요.
• 저장하지 않은 작업을 정리한 뒤 wsl.exe --shutdown을 실행하세요.
• 재시작 후 PID 1, systemd 전체 상태, 실패 유닛을 차례로 확인하세요.
• 서비스 하나가 실패하면 상태 출력과 부팅 로그를 저장하고 반복 재시작을 멈추세요.
• 자동 시작이 필요 없는 개발용 서비스는 enable하지 않고 수동으로 실행하세요.

자주 묻는 점

WSL을 다시 설치해야 하나요?

대부분은 그럴 필요가 없어요. WSL2 여부, /etc/wsl.conf의 문법, 전체 인스턴스 재시작, PID 1 순서로 확인하면 됩니다. 배포판을 등록 해제하는 작업은 마지막 수단으로 남겨 두세요.

systemd를 켜면 모든 서비스가 자동으로 실행되나요?

아니요. systemd가 실행되는 것과 각 서비스가 enable 된 것은 별개예요. 서비스별로 is-enabled, is-active를 확인해야 합니다.

항상 켜져 있는 Linux 서버가 필요하면 WSL이 맞나요?

개발·테스트 환경에는 잘 맞지만, 중단 없는 운영 서버가 목적이면 백업·재시작·네트워크·수명 주기를 따로 관리해야 합니다. WSL은 Windows와 함께 재부팅되며, 배포판이 종료되면 내부 서비스도 멈춘다는 점을 운영 조건에 넣어야 해요.

관련해서 WSL2 설치 방식 자체가 헷갈린다면 Windows에서 Native WSL2와 설치 흐름을 구분하는 글을 먼저 보고, 저장 공간 문제를 함께 겪고 있다면 Windows 11 Storage Sense 사용 순서도 이어서 확인해 보세요. systemd를 켜는 일은 명령 한 줄보다, 어떤 서비스가 언제 살아 있어야 하는지 정하는 작업에 가깝습니다.

Sources

• [1] Use systemd to manage Linux services with WSL | Microsoft Learn
• [2] Basic commands for WSL | Microsoft Learn