게시 됨 업데이트 됨9분안에 읽기 (약 1283 단어)

시스템이 절전 모드(Sleep/Suspend)에 진입했었는지 확인하려면, 시스템이 저전력 상태로 전환되었다가 다시 깨어난 기록을 로그에서 찾아야 합니다. 우분투와 같은 리눅스 시스템에서는 systemd-sleep 유틸리티의 활동을 추적하는 것이 가장 정확합니다.

1. journalctl을 이용한 확인 (가장 확실함)

시스템이 잠자기에 들어갈 때와 깨어날 때 남기는 고유한 로그 메시지를 검색합니다.

  • 잠자기 및 깨어남 기록 전체 보기:

    1
    2
    journalctl | grep -iE "sleep|suspend|resume"

  • 특정 시점(예: 오늘)의 기록만 보기:

    1
    2
    journalctl --since today | grep -iE "PM: suspend|PM: resume"

로그 해석 팁:

  • PM: suspending system...: 시스템이 잠자기에 진입하기 시작함.
  • PM: suspension of devices complete: 장치들이 절전 상태로 전환됨.
  • PM: resume from suspend: 시스템이 다시 깨어남.

2. systemd-sleep 전용 로그 확인

우분투는 잠자기 동작을 systemd-sleep 프로세스가 관리합니다.

1
2
journalctl -u systemd-suspend.service

이 명령을 실행하면 시스템이 언제 “Started Suspend” 되었고 언제 “Finished Suspend” 되었는지 타임라인별로 깔끔하게 확인할 수 있습니다.

3. /var/log/syslog 직접 뒤져보기 (구형 방식)

최신 시스템이 아니거나 journalctl 사용이 번거로울 때 사용합니다.

1
2
grep -i "systemd-sleep" /var/log/syslog

4. 노트북 전원 관리 확인 (RTX 4060 노트북 특유 사항)

사용 중인 RTX 4060 노트북 환경에서 시스템이 잠자기에 들어갔는지, 아니면 그냥 화면만 꺼졌는지(Screen Dimming) 구분하는 것이 중요합니다.

  • 현재 잠자기 지원 모드 확인:
    1
    2
    cat /sys/power/state

(결과에 mem이 포함되어 있다면 RAM을 이용한 일반적인 절전을 지원하는 상태입니다.)

  • 마지막 잠자기 성공 여부:
    1
    2
    dmesg | grep -i "hash matches"

(성공적으로 절전 모드에 진입했다가 깨어났다면 커널 메시지에 관련 해시 기록이 남습니다.)

💡 요약: 지금 바로 확인하려면?

방금 전 그랩 로그에서 본 18:26 종료 기록 이전에 잠자기가 있었는지 확인하려면 아래 명령을 입력해 보세요.

1
2
journalctl -b -1 | grep -i "reached target suspend"

만약 아무 결과가 없다면, 시스템은 잠자기를 거치지 않고 바로 종료(Shutdown)된 것입니다.

로그 상에 Reached target Suspend가 나오나요, 아니면 바로 Shutdown 절차로 넘어가나요? 이를 통해 윈도우 호스트가 WSL을 단순히 재운 것인지 완전히 끈 것인지 판별할 수 있습니다.

이 에러는 11434 포트가 이미 다른 프로세스에 의해 점유되어 있어서 Ollama 서비스가 새로 시작되지 못하는 전형적인 상황입니다. 재시작 과정에서 이전 프로세스가 제대로 죽지 않았거나, 다른 서비스가 해당 포트를 가로챘을 가능성이 큽니다.

다음 순서대로 조치하면 즉시 해결됩니다.

1. 포트 점유 프로세스 확인 및 강제 종료

가장 먼저 어떤 녀석이 11434 포트를 잡고 있는지 확인해야 합니다. (net-tools 대신 ss와 ip 계열 명령을 사용합니다.)

1
2
3
# 11434 포트를 사용 중인 프로세스의 PID 확인
sudo ss -tulpn | grep 11434

출력 결과에서 pid=12345와 같은 번호를 찾으세요. 만약 프로세스가 있다면 아래 명령으로 강제 종료합니다.

1
2
3
4
5
6
# 특정 PID 종료 (예: PID가 12345인 경우)
sudo kill -9 12345

# 또는 ollama 이름을 가진 모든 프로세스 한 번에 정리
sudo pkill -9 ollama

2. Ollama 서비스 정상 재시작

프로세스를 정리했다면 이제 systemd를 통해 서비스를 다시 깨끗하게 올립니다.

1
2
3
sudo systemctl daemon-reload
sudo systemctl restart ollama

상태를 확인하여 active (running)이 뜨는지 봅니다.

1
2
sudo systemctl status ollama

3. WSL2 mirrored 모드 특유의 이슈 점검

현재 데스크탑에서 networkingMode=mirrored를 사용 중이신데, 이 모드에서는 Windows 호스트의 포트와 WSL2의 포트가 공유됩니다.

  • 원인: 만약 Windows용 Ollama(Ollama for Windows)가 설치되어 있고, 윈도우 부팅 시 자동 실행되었다면 Windows 쪽 프로세스가 이미 11434를 선점한 것입니다.
  • 해결법: Windows 작업 표시줄 오른쪽 하단 트레이 아이콘에서 Ollama 아이콘을 찾아 Quit 하세요. 그 후 WSL2에서 다시 서비스를 시작하면 정상적으로 작동할 것입니다.

💡 요약 및 예방

  1. 원인: Address already in use (포트 충돌).
  2. 범인: 종료되지 않은 구형 Ollama 프로세스 혹은 Windows용 Ollama 프로그램.
  3. 조치: sudo pkill -9 ollama 후 sudo systemctl restart ollama.

만약 위 과정을 거쳤는데도 계속해서 bind: address already in use가 뜬다면, Windows에서 실행 중인 Ollama가 범인일 확률이 99%입니다. Windows 쪽을 먼저 종료해 보세요!

https://thinkbee.github.io/linux-power관련-c50ba68483f7/

Author

Gangtai Goh

Posted on

2026-05-18

Updated on

2026-05-18

Licensed under

최근 글

×