apt Could not get lock /var/lib/dpkg/lock-frontend 30초 진단·복구 런북

apt could not get lock /var/lib/dpkg/lock-frontend 에러 30초 진단·복구 런북

온콜 중에 이 글에 들어왔다면 인사말은 생략하겠습니다. 지금 당신의 터미널엔 아마 아래 셋 중 하나가 떠 있을 겁니다.

E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock

지금 절대 하면 안 되는 것부터 말합니다. 검색 결과 상단에 흔히 나오는 sudo rm /var/lib/dpkg/lock* 를 반사적으로 치지 마세요. 지금 그 락을 잡고 있는 게 정상 동작 중인 apt 트랜잭션일 수 있고, 그 상태에서 락을 지우고 재실행하면 dpkg 데이터베이스가 깨져서 복구가 몇 배 더 오래 걸립니다. 순서는 딱 하나입니다. 먼저 누가 락을 잡았는지 확인하고, 그 다음에 판단합니다.

30초 원인 판별표: 4계층 진단

락 에러의 원인은 실무상 딱 4가지로 수렴합니다. 위에서부터 순서대로 확인하세요.

핵심은 fuser 결과입니다. PID를 하나라도 뱉으면 살아있는 프로세스이니 죽이지 말고 기다리세요. 아무것도 안 나오면 그때가 stale lock을 의심할 시점입니다.

sudo fuser /var/lib/dpkg/lock-frontend      # 락 파일을 여는 PID 출력 (비면 stale 의심)
ps aux | grep -E 'apt|dpkg|unattended'      # 실제 프로세스 명세 확인

락 파일 4종은 단계가 다릅니다

lock-frontend만 있는 게 아닙니다. apt는 단계별로 다른 락을 잡습니다.

즉 lists/lock 에러는 update 단계, lock/lock-frontend는 install 단계에서 충돌한 것입니다. 무엇이 잡혔는지 보면 어느 작업과 부딪혔는지 역추적됩니다.

"lock 파일을 그냥 rm 해도 되나요?"

결론: 대부분의 경우 안 됩니다. rm이 위험한 이유는 락이 단순 플래그가 아니라 진행 중인 트랜잭션의 표식이기 때문입니다. 삭제 후 재실행하면 두 개의 dpkg가 동시에 DB를 쓰게 되고, 반쯤 설치된 패키지 상태가 그대로 남습니다.

안전한 순서는 flowchart처럼 세 단계로 못 박아 두세요.

1. fuser/ps로 점유 프로세스 확인 — 살아있으면 다음으로 가지 않는다
2. 정상 대기 — unattended-upgrades/cloud-init이면 보통 1~3분 내 자동 해제
3. 정말 stale일 때만 삭제 — fuser가 비었고, 관련 프로세스도 없음을 두 번 확인한 뒤에만

복붙 복구 스니펫 3안

A안 — 그냥 대기·재시도 (가장 안전, 1순위)

# 다른 apt/unattended-upgrades가 끝날 때까지 락이 풀리길 반복 대기
while sudo fuser /var/lib/dpkg/lock-frontend >/dev/null 2>&1; do
  echo "락 점유 중... 5초 후 재확인"; sleep 5
done
sudo apt-get install <패키지명>             # 락 해제 후 재시도

B안 — 프로세스 안전 종료 (멈춰버린 apt일 때)

sudo fuser /var/lib/dpkg/lock-frontend      # 점유 PID 확인 (예: 2481)
sudo kill 2481                              # 먼저 SIGTERM으로 정상 종료 요청
sleep 10                                    # 트랜잭션 정리 시간 부여
sudo fuser /var/lib/dpkg/lock-frontend      # 죽었는지 재확인
sudo kill -9 2481                           # 정말 안 죽을 때만 최후의 SIGKILL
sudo dpkg --configure -a                    # ★ kill -9 후엔 반드시 DB 정합성 복구

kill -9로 강제 종료했다면 dpkg --configure -a는 선택이 아니라 필수입니다. 중단된 설정 단계를 마저 끝내 DB를 정상 상태로 되돌립니다.

C안 — stale lock 정리 후 완전 복구

sudo fuser /var/lib/dpkg/lock-frontend      # 반드시 "빈 출력" 확인 (아무 PID 없음)
ps aux | grep -E 'apt|dpkg'                 # 관련 프로세스 없음 재확인
sudo rm /var/lib/dpkg/lock-frontend         # 여기까지 통과했을 때만 삭제
sudo rm /var/lib/dpkg/lock
sudo dpkg --configure -a                    # 중단된 트랜잭션 마무리
sudo apt-get --fix-broken install           # 깨진 의존성 자동 복구

실무 경험 한마디: 온콜에서 가장 많이 본 실수는 "A안으로 20초만 기다렸으면 끝날 일을 B/C안으로 강제 종료해서 오히려 30분을 태운" 케이스입니다. cloud-init이나 unattended-upgrades가 붙은 락은 거의 항상 스스로 풀립니다. 급할수록 A안부터 가세요.

결론: 재발 방지 체크리스트

cloud-init 기반 오토스케일링과 이미지 프로비저닝이 늘면서 "부팅 직후 apt 락" 사례가 폭증했습니다. Ubuntu 서버 이미지는 unattended-upgrades가 기본 활성화라, 인스턴스가 뜨자마자 백그라운드에서 apt를 돌립니다. IaC로 그 위에 또 apt install을 던지면 충돌은 예정된 일입니다.

• CI/프로비저닝에서 락 타임아웃 대기 — Ubuntu 24.04 LTS 기준, 실패 대신 최대 60초 기다립니다.
  Bash복사

  sudo apt-get -o DPkg::Lock::Timeout=60 install -y <패키지명>

• cloud-init 완료를 명시적으로 기다린 뒤 apt 실행
  Bash복사

  sudo cloud-init status --wait && sudo apt-get update

• unattended-upgrades 타이밍 조정 — 프로비저닝 창과 겹치지 않게 apt-daily.timer 스케줄을 옮기거나, 이미지 빌드 시 일시 비활성화
• Ansible/Terraform에선 apt 작업을 직렬화 — 여러 태스크가 동시에 락을 잡지 않도록 lock_timeout 옵션 활용

자주 묻는 질문 (FAQ)

Q. sudo rm /var/lib/dpkg/lock-frontend 해도 안전한가요? A. fuser로 점유 프로세스가 없음을 확인한 stale 상태에서만 안전합니다. 살아있는 프로세스가 있으면 DB 손상 위험이 커서 절대 삭제하면 안 됩니다.

Q. kill -9로 apt를 죽였는데 이후 뭘 해야 하나요? A. 반드시 sudo dpkg --configure -a를 실행해 중단된 트랜잭션을 마무리하고, 이어서 sudo apt-get --fix-broken install로 의존성을 복구하세요.

Q. 인스턴스가 막 부팅됐는데 계속 락 에러가 납니다. 원인이 뭔가요? A. cloud-init 또는 unattended-upgrades가 백그라운드에서 apt를 점유 중일 가능성이 높습니다. cloud-init status --long으로 확인하고, cloud-init status --wait로 완료를 기다린 뒤 실행하세요.