결론부터 말하면, 이 메시지는 다른 apt나 dpkg 프로세스가 패키지 시스템 잠금을 쥐고 있다는 뜻입니다. 그 작업이 끝나거나 취소되기를 기다린 뒤 명령을 다시 실행하면 됩니다. 어떤 프로세스가 잠금을 쥐고 있는지는 ps와 lsof로 확인할 수 있고, 잠금 파일을 지우는 방법은 권하지 않습니다.
이 메시지가 나오는 이유
우분투는 한 번에 하나의 패키지 설치나 제거 작업만 허용합니다. 패키지 작업을 하는 프로세스는 /var/lib/dpkg/lock-frontend 파일에 잠금을 걸어 둡니다. 이 잠금이 걸려 있는 동안 두 번째 apt install을 실행하면 잠금을 얻지 못해 이 메시지가 나옵니다.
테스트 환경과 방법
Ubuntu 24.04.4 LTS 서버(apt 2.8.3)에서, 같은 머신에 접속한 터미널 두 개로 직접 재현했습니다.
- 터미널 A에서
sudo apt install gimp를 실행했습니다. 확인 질문(Do you want to continue? [Y/n])이 나왔고, 답하지 않고 그대로 두었습니다. - 터미널 B에서
sudo apt install figlet을 실행했습니다. - 터미널 B에서
sudo apt update,ps,lsof도 실행해 상태를 확인했습니다. - 터미널 A에서
n을 입력해 취소(Abort.)한 뒤, 터미널 B에서sudo apt install figlet을 다시 실행했습니다.
| 번호 | 위치 | 명령 | 결과 |
|---|---|---|---|
| 1 | 터미널 B | sudo apt install figlet | Waiting for cache lock 줄이 계속 반복됨 |
| 2 | 터미널 B | sudo apt update | 정상 완료 |
| 3 | 터미널 B | ps (apt, dpkg로 걸러서) | apt install gimp 프로세스가 보임 |
| 4 | 터미널 B | sudo lsof /var/lib/dpkg/lock-frontend | 잠금 파일을 연 apt 프로세스 하나가 보임 |
| 5 | 터미널 B | 터미널 A에서 n으로 취소한 뒤 sudo apt install figlet | 기다림 없이 설치됨 |
실제로 나온 메시지
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process <PID> (apt)이 서버에서는 오류로 바로 끝나지 않고, 같은 줄이 계속 반복되며 잠금이 풀리기를 기다렸습니다. 메시지 끝에 잠금을 쥔 프로세스의 번호와 이름이 나오므로 원인을 추측할 필요가 없습니다.
잠금을 쥔 프로세스 찾기
다른 터미널에서 아래 명령을 실행합니다.
ps aux | grep -E 'apt|dpkg' | grep -v grep아래 출력은 줄여서 보여드리며, 프로세스 번호는 자리표시자로 바꿨습니다.
root <PID-1> sudo apt install gimp
root <PID-2> sudo apt install gimp
root <PID> apt install gimp이 테스트에서는 오류 메시지의 프로세스 번호가 apt install gimp 프로세스의 번호와 같았습니다. 이어서 잠금 파일을 연 프로세스를 lsof로 확인했습니다.
sudo lsof /var/lib/dpkg/lock-frontendCOMMAND PID USER FD TYPE NAME
apt <PID> root 4uW REG /var/lib/dpkg/lock-frontend파일을 연 프로세스는 같은 apt 하나뿐이었습니다. lsof 표기에서 4uW의 W는 파일 전체에 쓰기 잠금이 걸렸다는 뜻입니다.
해결 방법
- 메시지에 나온 프로세스 번호와 이름을 확인합니다.
ps로 그 프로세스가 무엇인지 확인합니다. 다른 창에서 직접 실행한 apt 명령이라면 그 창으로 가서 작업이 끝나게 두거나 취소합니다.- 모르는 프로세스라면 끝나기를 기다립니다. 잠금 파일을 지우는 방법은 테스트하지 않았고 권하지 않습니다.
- 명령을 다시 실행합니다. 이 테스트에서는 다른 명령을 취소하자 기다림 없이 바로 실행됐습니다.
잠금 파일을 지우라는 설명을 따르기 전에
잠금 파일을 지우는 방법이 소개되는 경우가 있습니다. 저는 이 방법을 테스트하지 않았습니다. 다른 프로세스가 아직 작업 중일 수 있으므로, 먼저 위의 ps와 lsof로 누가 잠금을 쥐고 있는지 확인하는 것이 순서입니다.
apt update는 막히지 않았습니다
터미널 A가 잠금을 쥐고 있는 동안 터미널 B의 sudo apt update는 정상으로 끝났습니다. 이 테스트에서 한 번 관찰한 결과이고, 이 상황에서만 확인했습니다. 이미 다운로드 중인 경우처럼 다른 상황에서는 다를 수 있습니다.
직접 재현해 볼 때의 팁
이 테스트에서는 cowsay, figlet 같은 작은 패키지 한 개를 설치할 때 확인 질문이 나오지 않았고, 제거할 때는 질문이 나왔습니다. gimp는 확인 질문이 나왔고, 추가로 231 MB의 디스크를 쓴다는 안내가 함께 나왔습니다. 재현하려면 첫 번째 터미널에서 명령이 정말 멈춰 있는지 확인한 뒤 두 번째 터미널을 실행하세요. 질문에 y를 입력하면 패키지가 실제로 설치되므로 주의하세요.
테스트하지 않은 것
- 백그라운드 자동 업데이트가 원인인 경우처럼 같은 메시지가 나오는 다른 원인
- apt가 잠금을 기다리는 최대 시간
- 잠금 파일 삭제
- 다른 우분투 버전
같은 테스트를 영어로 정리한 글
같은 테스트를 영어로 정리한 글은 Ubuntu apt Error: Could not get lock /var/lib/dpkg/lock-frontend에서 볼 수 있습니다.