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

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

WSL2에서 Docker, PostgreSQL, Redis 같은 Linux 서비스를 다루다 보면 systemctl이 필요한 순간이 생깁니다. 하지만 /etc/wsl.conf에 설정을 넣었다고 곧바로 서비스가 살아나는 것은 아닙니다. 먼저 대상 배포판이 WSL2인지, systemd가 PID 1로 실행됐는지, 실패한 유닛이 무엇인지 순서대로 분리해 확인해야 합니다.[1]

systemd를 켠다는 뜻

systemd는 Linux에서 PID 1로 실행되며 부팅 과정과 서비스를 관리하는 역할을 합니다.[1] WSL2에서 systemd를 사용하면 배포판 안에서 서비스 유닛을 등록하고 systemctl status, systemctl enable 같은 명령을 사용할 수 있습니다.[1] 다만 Windows 서비스와 WSL 안의 Linux 서비스는 같은 수명 주기를 갖지 않습니다. WSL 배포판 인스턴스가 종료되면 그 안의 프로세스도 함께 멈추므로, 개발용 환경과 상시 실행 서버를 구분해야 합니다.

문제 해결 전에 현재 상태를 기록하기

PowerShell에서 기본 배포판과 버전을 먼저 확인합니다. Microsoft가 안내하는 기본 명령은 다음과 같습니다.[2]

wsl --status
wsl --list --verbose

VERSION이 2인지 확인하고, 배포판이 여러 개라면 실제로 작업할 이름을 기록하세요. 필요할 때 기본 배포판을 바꾸는 명령은 다음과 같습니다.

wsl --set-default <DistributionName>

이름은 wsl --list --verbose에 표시된 값을 그대로 사용해야 합니다. 추측한 이름을 넣으면 다른 배포판을 확인하거나 명령이 실패할 수 있습니다.

/etc/wsl.conf 설정과 재시작

대상 배포판 안에서 /etc/wsl.conf를 열고 기존 내용을 먼저 보관한 뒤 [boot] systemd=true 설정을 추가합니다. 이미 [boot] 섹션이 있다면 같은 키가 중복되지 않는지 확인하세요.

저장 후에는 Linux 터미널을 닫는 것만으로 설정이 반영되지 않을 수 있습니다. 작업 중인 파일과 개발 서버의 미저장 상태를 확인한 다음 PowerShell에서 모든 WSL 인스턴스를 종료하고 다시 실행합니다.[1]

wsl.exe --shutdown
wsl

--shutdown은 실행 중인 WSL 인스턴스를 내리는 명령이지 배포판을 삭제하는 명령이 아닙니다. 반면 wsl --unregister는 해당 배포판의 데이터와 설정, 설치된 소프트웨어를 영구적으로 제거하므로 systemd 문제를 해결하려고 먼저 실행하면 안 됩니다.[2]

systemd가 실제로 올라왔는지 확인하기

배포판을 다시 연 뒤 아래 명령을 순서대로 실행합니다.

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

1. ps -p 1의 프로세스 이름이 systemd인지 봅니다. PID 1이 다른 프로세스라면 개별 서비스보다 WSL 설정과 재시작부터 다시 확인해야 합니다.
2. systemctl is-system-running의 결과를 기록합니다. running이 아니어도 부팅 중이거나 일부 유닛이 실패했을 수 있으므로 실패 목록을 함께 봅니다.
3. systemctl --failed로 실패한 유닛을 찾고, 실행 중인 목록과 혼동하지 않습니다.

systemctl 자체가 연결 오류를 낸다면 PostgreSQL 같은 특정 서비스부터 재시작하지 마세요. 먼저 PID 1과 systemd가 실행됐는지 확인하는 것이 빠릅니다.

서비스 하나만 실패할 때

유닛 이름은 배포판과 설치 방식에 따라 다를 수 있으므로 목록에서 정확한 값을 찾습니다.

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줄 읽습니다. 로그에서는 포트 충돌, 설정 파일 문법, 권한, 데이터 디렉터리 소유권처럼 최초로 나타난 오류를 찾으세요. “실행되지 않는다”는 증상만 보고 restart를 계속 반복하면 원인이 가려질 수 있습니다.

설정을 고친 뒤 실패 표시를 정리하고 한 번 재시도할 수 있습니다.

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

재시작 후에도 실패하면 명령 반복보다 로그의 첫 오류를 해결하는 편이 안전합니다. 데이터베이스라면 데이터 디렉터리의 권한과 소유자를 확인하되, 익숙하지 않은 상태에서 임의로 권한을 넓히거나 데이터를 삭제하지 마세요.

자동 시작은 필요한 서비스만

systemd가 켜져 있다고 모든 서비스가 자동 실행되는 것은 아닙니다. 장시간 필요한 서비스만 다음처럼 설정하세요.

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

enable은 다음 systemd 시작 때 자동 실행 연결을 만들고, --now는 지금 시작합니다. is-enabled와 is-active를 나눠 보면 자동 시작 설정과 현재 실행 상태를 혼동하지 않습니다. 잠깐 쓰는 개발용 서비스라면 enable 없이 필요할 때 start하는 편이 WSL 시작 시간을 줄일 수 있습니다. 되돌릴 때는 sudo systemctl disable --now <unit-name>를 사용합니다. 이 명령은 서비스 자동 시작과 실행만 바꾸며 패키지와 데이터 삭제는 하지 않습니다.

증상별 다음 행동

적용 전후 체크리스트

• 대상 배포판의 이름과 WSL2 버전을 기록합니다.
• /etc/wsl.conf를 백업하고 기존 [boot] 설정을 확인합니다.
• 미저장 작업을 정리한 뒤 wsl.exe --shutdown을 실행합니다.
• PID 1, systemd 상태, 실패 유닛을 차례로 확인합니다.
• 서비스 실패 시 상태 출력과 부팅 로그를 저장하고 반복 재시작을 멈춥니다.
• 자동 시작이 꼭 필요한 서비스만 enable합니다.

자주 묻는 질문

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

대부분은 재설치보다 WSL2 여부, /etc/wsl.conf 문법, 전체 인스턴스 재시작, PID 1 순서를 확인하는 것이 먼저입니다. --unregister는 데이터가 사라지는 작업이므로 마지막 수단으로 남겨 두세요.[2]

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

아닙니다. systemd가 실행되는 것과 서비스별 enable 설정은 별개입니다. 필요한 유닛마다 is-enabled와 is-active를 따로 확인해야 합니다.

상시 운영 서버로 WSL을 써도 되나요?

개발·테스트에는 편리하지만 Windows 재부팅과 배포판 종료가 서비스 수명에 영향을 줍니다. 중단 없는 운영이 목적이면 백업, 재시작, 네트워크, 장애 대응을 별도로 설계하고 WSL이 그 조건에 맞는지 판단하세요.

WSL 설치 방식 자체가 헷갈리면 Native WSL2와 설치 흐름을 구분하는 글을 참고하고, 저장 공간을 함께 관리하려면 Windows 11 Storage Sense 사용 순서를 이어서 확인해 보세요.

WSL 수명과 운영 목적을 구분하기

개발 중인 서비스를 필요할 때만 켜는 환경이라면 수동 시작이 단순합니다. 반대로 Windows를 켤 때마다 데이터베이스가 필요하다면 자동 시작 여부뿐 아니라 배포판이 언제 실행되고 종료되는지까지 기록해야 합니다. Windows 재부팅 뒤 서비스가 안 보인다고 곧바로 유닛 설정이 망가졌다고 보지 말고, 배포판을 다시 연 뒤 PID 1과 서비스 상태를 새로 확인하세요.

데이터가 있는 서비스는 복구 명령보다 백업과 저장 위치 확인이 먼저입니다. 포트 번호를 바꾸거나 권한을 수정하기 전에는 어떤 프로세스가 해당 포트를 사용 중인지, 데이터 디렉터리가 어느 사용자 소유인지 기록하세요. 여러 원인을 동시에 바꾸면 무엇이 해결에 영향을 줬는지 알 수 없으므로 한 번에 한 항목만 조정하고 상태와 로그를 남기는 것이 좋습니다.

Sources

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